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:
- Lack of maintainability
- Lack of quality
- developers sometimes make manual changes in the generated code
- The code change is not localized to a certain file, increasing the probability of breaking existing functionality
- You need a very disciplined team to use auto-generated code
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.
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.
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.
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?
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.