Should "generated code" only be used for scaffolding? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by ed开发者_如何转开发iting this post.

Closed last year.

Improve this question

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.

---

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:

• RPC code generated by rpcgen
• The (de)serializers generated by protobuf
• The assembly code generated by your C/C++ compiler
• The .NET XML mapping code generated by xsd.exe
• Binding glue code generated by Swig
• GUI code generated by designer tools.

---

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).

---

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

---

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.

---

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).

---

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.

---

If you don't touch generated code you cannot go on using generator until the end of development process except newly added parts. As a developer i should use a code generator while going on project development. Zontroy is a good example to satisfy this requirement. As using "protect block" you can keep safe your custom code inside a generated file. As a result you are able to regenerate all code files when you need.