Are code generators bad?

Question

I use MyGeneration along with nHibernate to create the basic POCO objects and XML mapping files. I have heard some people say they think code generators are not a good idea. Wha

Answer 1

The biggest problem I've had with code generators is during maintenance. If you modify the generated code and then make a change to your schema or template and try to regenerate you can have problems.

One problem is if the tool doesn't allow you to protect changes you've made to the modified code then your changes will be overwritten.

Another problem I've seen, particularly with code generators in RSA for web services, if you change the generated code too much the generator will complain that there is a mismatch and refuse to regenerate the code. This can happen for something as simple as changing the type of a variable. Then you are stuck generating the code to a different project and merging the results back into your original code.

Answer 2

It can really become an issue with maintainability when you have to come back and cant understand what is going on in the code. Therefore many times you have to weigh how important it is to get the project done fast compared to easy maintainability

maintainability <> easy or fast coding process

Answer 3

I've written a few code generators before - and to be honest they saved my butt more than once!

Once you have a clearly defined object - collection - user control design, you can use a code generator to build the basics for you, allowing your time as a developer to be used more effectively in building the complex stuff, after all, who really wants to write 300+ public property declarations and variable instatiations? I'd rather get stuck into the business logic than all the mindless repetitive tasks.

Answer 4

Code generators are not bad, but sometimes they are used in situations when another solution exists (ie, instantiating a million objects when an array of objects would have been more suitable and accomplished in a few lines of code).

The other situation is when they are used incorrectly, or coded badly. Too many people swear off code generators because they've had bad experiences due to bugs, or their misunderstanding of how to correctly configure it.

But in and of themselves, code generators are not bad.

-Adam

Answer 5

Code generators are great assuming it is a good code generator. Especially working c++/java which is very verbose.

Answer 6

Code generators are great, bad code is bad.

Most of the other responses on this page are along the lines of "No, because often the generated code is not very good."

This is a poor answer because:

1) Generators are tool like anything else - if you misuse them, dont blame the tool.

2) Developers tend to pride themselves on their ability to write great code one time, but you dont use code generators for one off projects.

We use a Code Generation system for persistence in all our Java projects and have thousands of generated classes in production.

As a manager I love them because:

1) Reliability: There are no significant remaining bugs in that code. It has been so exhaustively tested and refined over the years than when debugging I never worry about the persistence layer.

2) Standardisation: Every developers code is identical in this respect so there is much less for a guy to learn when picking up a new project from a coworker.

3) Evolution: If we find a better way to do things we can update the templates and update 1000's of classes quickly and consistently.

4) Revolution: If we switch to a different persistence system in the future then the fact that every single persistent class has an exactly identical API makes my job far easier.

5) Productivity: It is just a few clicks to build a persistent object system from metadata - this saves thousands of boring developer hours.

Code generation is like using a compiler - on an individual case basis you might be able to write better optimised assembly language, but over large numbers of projects you would rather have the compiler do it for you right?

We employ a simple trick to ensure that classes can always be regenerated without losing customisations: every generated class is abstract. Then the developer extends it with a concrete class, adds the custom business logic and overrides any base class methods he wants to differ from the standard. If there is a change in metadata he can regenerate the abstract class at any time, and if the new model breaks his concrete class the compiler will let him know.