When a system generates source code which is used by a system, should that code only be used for scaffolding (as in rails) where the user "fills in the blanks", or is there a case for generated code that is created and never amended by anyone except the code generator.
+1
A:
If you create GUIs in Java with Netbeans, then there are parts in the code that should not be changed by the developer, otherwise the GUI builder doesn't work properly anymore.
I guess this is such a case and (most?) GUI builders work that way.
Felix Kling
2010-02-15 09:37:48
+1
A:
No one right answer to this one.
Generally - generated code should never be touched by a user, in case it gets regenerated, overwriting all user changes.
If this is a one off generation and will never be done again, then by all means do change it. But if your language supports it, make changes in a separate file (for example, C# allows you to have a class span several files, as a "partial" class).
Oded
2010-02-15 09:38:32
+3
A:
In my experience it's more common to have generated code that you're not supposed to touch than systems generating skeleton code for you. Both methods are fine, but they solve different problems. Here's some examples of generated code you should not touch:
nos
2010-02-15 09:49:33
+1
A:
It depends on your code generator:
If code generation is a destructive process (i.e., whatever you changed is lost), generated code should not be amended.
If code generation allows to fill in blanks and remember their contents during code generation process, you can use it as scaffolding (as long as you change only identified blanks).
mouviciel
2010-02-15 09:56:44
+1
A:
Hello,
A good code generator is template based and not a black boxed solution like those stated above. It should also have a way for you to actively regenerate smartly without losing your changes. I think a code generator should be both, it should allow for a closed (read only but modifiable) system while at the same time allowing functionality or behavior to change if needed via a template.
Lets put this into perspective... If something is a complete black box and you shouldn't ever modify it... Thats basically saying it works in most cases so don't even touch it or look at it. I think that is a bad approach because then you have no idea of the implementation or any harmful side effects it may have while being locked into one solution... Just remember there are 100 ways to solve an issue.
Thanks -Blake Niemyjski
Blake Niemyjski
2010-02-17 01:30:01
A very interesting angle on this problem I think, about whether it is good to have a complete black box framework
Zubair
2010-02-17 07:54:18
+1
A:
It may be worth noting that many code generators for .NET use the .NET "partial class" mechanism. This permits the code that's actually generated to remain the same, while allowing the developer to add to the generated class in a way that will not be overwritten by later code regeneration.
This can be used in addition to inheritance and virtual members in the generated code to provide quite a lot of flexibility, while allowing the code generator to dictate the structure of the code as well as filling in base functionality.
John Saunders
2010-02-17 01:42:15