Generated code is evil

Generated code is evil

Actually, is it really the case?

Generated code is evil, bad and a design smell. Interestingly that's a widely known opinion among a significant part of the software development community. There are quite a few arguments to back that position. Again, the cited stuff is mostly taken from an answer on Programmers.SE, just because this particular answer had them all:

Coincidently it happens that I have a faible for stuff like this. I am an active Committer at the Apache Thrift project, I have used the Eclipse Xtext framework very successfully in a number of projects, and I do have also certain interest in MDA/MDSD and last not least the absolutely awesome Haxe Toolkit. So I think I can speak with some authority gained from these very practical experiences, when I say that really all of the above mentioned reasons are just that - plain wrong. But let's go through them step by step.


My problem with auto generated code is its lack of maintainability. If there is a small change in the database then you have to refresh the entire generated code section and make sure that only the intended change have gone in.

If your code generator produces bad code get rid of it
First, as someone else already pointed out, how much will it really take to recreate all the generated stuff? It surely is not a matter of hours, it probably will not even take much over a minute, even for complex projects. Next, how important is maintainability of the generated code really? Where I fully, absolutely and with no reservations do agree with: the code should be readable, it should be debuggable and it should be accessible to the developer. If your code generation tool can not do this, there is only one sane decision: Get rid of it. Or, if you wrote it yourself, do it again. It is possible to generate code with a certain quality, and it is not that hard.

And if you are not using any code repository which does not tell you the changes in the code then it is much more difficult to find the code changes.

Normally you should not even have to care about changes in the code. It depends, however, what the origin of the code generation tool is. The single best solution to unwanted or unexpected breaking changes is to put the code generation tool itself under version control.

Tracking code changes in generated code sometimes can be a valid point. So if that matters, tracking the generated stuff in the repo can be an option indeed. Note that I do not favour or recommend it, but there are some situations where this is the way to go.


It also means that the entire component should be tested again fully for all scenarios.

Same here. It mainly depends on who wrote the code generator. If it is a trustworthy source, both with respect to code quality and security, there should not be that much need to care about it at all. If the code generator comes from an rather untrusted source, it may be time to question why you are continuing to rely on such a tool at all.

Generated code should never be changed manually
Note that I do not speak against tests. Of course you have to test everything, but that is true for the manually written code as well. And although a code generator can be a great tool for multiplying bugs (more efficent than copy+paste, I can tell you that), I have seen much more, and more serious bugs in manually written code than I ever found in generated code. People do make mistakes, that's a fact of life, but generated code is typically much more tested and thought through than manually written stuff.

Code generation rule #1

Also, I have noticed that developers working on the legacy generated code sometimes make manual changes in the generated code instead of generating the auto generated code section again. After a period of time it becomes almost impossible to replace the auto generated code.

That's of course a bad thing to happen, no question about it. This is the number #1 rule: Generated code should never ever be changed manually, under no circumstances, never ever. Except if there is really no other damn way to solve a particular problem - which is a quite rare situation. Thus you should avoid mentioning that exception at all, persist on rule #1, keep it for you and hand it out only if such an emergency situation arises. Don't fail here, this is the most critical piece of the puzzle.

Locality of changes

Code First of Entity Framework seems to me a much better option. The code change is localized to a certain file so less chances of breaking any existing functionality.

It does not matter how many files are touched
That's a great argument, I don't even know where to start. The code change is localized (sic) to one file only ... may I ask how often that happens with your regular, hand-written code? And on top of it, you do have only one place to change - your IDL/DSL!

Next, who cares how many files need to be re-generated and changed for a particular IDL or DSL change? Nobody, because it does not matter! The only thing that matters is whether or not the resulting code works as expected and fulfills all the criterions regarding performance, reliability, security and so on. These are the benchmarks, plus of course productivity, that you should look at!

Finally, you got less chances of breaking anything if you use a good code generation tool (as outlined above), no matter how many files are touched. Lastly, have you ever cared one single time about the number of bytes that need to be touched by Compiler and Linker in order to produce or re-link the binaries you are working on?

The Team

So in nutshell, if you have a very disciplined team who does not touch the generated sections and also diligently covers all the test scenarios using Unit Tests ...

I try to be polite. Let me put it that way: If your programmers are not able to, or do not want to, learn such a simple rule as "Thou shalt not edit generated files", it is very likely that you already got some other, probably more serious, problems than just code generation issues.

... then by all means you can go for generated code approach but try to have Code First approach as much as possible.

No. You just do it. Go for it, or go out of business. It is that simple. Really.