Personally, i am also for not using code-generation if possible. We have a framework which has lots of functionality, and we are keep adding it.

With code generation i would not image how would i be able to change something.

Technically looking at the problem, code generation solves a problem of a loop. That is, based on a standard set, create lots of similar code. So why not just abstract that similar code into some class, and then just make a simple for loop and iterate? That would be the result of code generation.

Of course, one thing i use code generation is to generate an initial draft of my WinForm application window. After i have initial design, i still wire up all code manually, all events, and add custom controls dynamically either at startup time or at run-time.

But hey, if code generation works for you, knock yourself out

taking that idea one step further leads me to this:

why not create higher-level reusable classes that contain the code that otherwise would be generated?

which is pretty much what i meant with:

“Always keep in mind that code generation is usually a solution to a problem that wasn’t solved properly in the first place.”

Replace “code generation” in your piece with “hammer” or “guns”, such as “Beware The Evils Of Hammers”.

Try the other one : “Beware The Evils Of Guns” … Sounds like pretty solid advice to me .

Ooh, and one thing I truly don’t understand is generating tests. If they can be generated why not define a higher level tests that contains the logic (and/or architecture) you now put in the test generator.

For an example of how code generation can get complex very quickly, see this article from Visual Studio Magazine . The question was “I’m working with Entity Framework (EF), and I’ve run into a problem. All of the generated properties are marked with the DataMember attribute … Can I remove these attributes?”. The answer runs to almost four pages in the printed magazine!

- drop the code generation: check in the generated files and remove the generation from your build files;
- for making a tiny change in one particular source file, introduce a conditional in the appropriate template.

The second option is the worst one, of course, but could be justifiable when you’re gradually moving away from your current solution.

A mix of both options would be to have your template skip certain files, which might be least hacky.

but i didn’t really state that Code Generation _in general_ is evil. But when you’re generating too much code, and depending on it in too many places, i think it definitely is.

and seriously, the O/R layer never changes? Please tell me i misread that…

Used well, it does the 80% in no time flat, and the 20% tricky stuff has more time to be developed by hand. Note, code generation will never help you generate the whole nut! It also helps setup a lot of code that adheres to internal standards.

It’s not for:

- generating code in areas where the design is still in flux
- generating incorrect code
- generating incorrect architecture

Replace “code generation” in your piece with “hammer” or “guns”, such as “Beware The Evils Of Hammers”. It’s just a tool. Inherent in generators is the potential, like any other tool, for ignorance and/or malice. Most common issue is no easy way to control the output, and no versioning/backwards compatibility with template changes.

Saying a code generator is evil is like saying compilers are evil, because a code generator is basically a simple “compiler” for a DSL.

For those who think merely improving the generated code through the templates is the solution to the problem, i wonder on what kind of projects you guys use code generation on. For small to medium projects, it’s probably not that big of an issue. For a large project, it’s really not that simple.

Yes, the design of the of the generated code is indeed pretty bad. However, due to the fact that a whole lot of that code is generated (and used), it becomes much harder (if not impossible in some cases) to try to improve that design.

i’ve seen good code generation as well, and if the generated code enables loosely-coupled systems, then that at least increases your options. But i do think that as the project increases in size, any kind of code generation eventually becomes more of a problem than the solution it was originally ment to be.

As for the duplication… maybe you’ve seen some really great code generators, but in most cases that i’ve seen, the generated code often has a lot of duplicated code in it. Or perhaps you ment duplicated efforts instead of duplicate code. Either way, writing reusable code could solve both issues and i think it offers you more flexibility in the long run.

I have successfully used the Open Source tool MyGeneration to generate a DAL. My experience is that once you understand and buy into the model of the tool or framework, you don’t have a problem. If you misuse the tool/framework, you can cause problems for yourself.

It sounds more like the generated code was not flexible enough to handle changing requirements. This, to my mind, does not make CG evil. I suspect your team may have the same amount of work to refactor computer-generated code as with hand-generated. Thus, the technical debt is not in the method (CG) but in the design used to build the CG templates.

In this case, one of the biggest problems was that the manually written code was very tightly coupled to the generated code… trying to reduce coupling by using interfaces proved to be impossible because every possible way of creating one of the generated components turned out to be used at least somewhere in the system. We couldn’t even make that change without introducing hundreds of compiler errors in manually written code. Now, as i mentioned in my post, if it was merely a case of fixing some syntax errors or reference types, it woulnd’t have been that big of an issue.

Now, again as i mentioned in the post, if you need to change the behavior of the generated code, and the manually written code expects certain things to happen and certain things not to happen, then you’re in a pretty bad situation because you simply can’t change it, unless you want a couple of developers to fix hundreds of compiler errors for a few days. Once that’s done, you’ll probably need to modify a lot of manually written code where assumptions were made on the behavior of the generated code.

The point is, because it is generated, you can’t easily change it. The larger the project is, the harder it becomes to make changes to the code generation. And we can’t simply turn off the code generation either, because then we’d have to manually maintain all of that shitty code whenever database changes occur. All in all, it’s probably about a 1000 classes at this point, and a lot of them contain very similar code. Which probably would’ve been written in a more reusable manner had it been written manually from the start. And then we’d at least have more options on making changes when needed or wanted.

I’ve seen lots of good code generation that create loosely-coupled systems that preserve the ability to change the template when needed.

Now, in my view, code generation shouldn’t be rushed to, instead relying on it as a method of eliminating a type of duplication.

Again, I just don’t see your point. O/R entities and persistence code (which presumably this was) will be used everywhere, whether it was generated or not. I just don’t see how the fact that the code was generated in your example is relevant. By the sounds of it, you have bad code that is used extensively throughout the system. The code happened to be generated. If the code generated was good code, would it still be a problem?

The compiler comparison doesn’t really hold up… the generated machine language will (in most cases) not be used by something else that needs to be maintained manually.

In our case, most of the things you could do with the generated code could be done in more than one way. Every possible usage scenario was being used at least somewhere in the application’s code base. And not just in a few places, but pretty much all over the code base. This made it pretty much impossible to make changes in the templates that would be used to generate the code

I find this a bit vague too. Was the generated code altered? Or did new code rely on implementation details of the generated code? Generally speaking I can’t really see a fundamental difference between generating code from a high level description on the one hand and a compiling a program in written in a high level language to machine code on the other. (I can see practical differences though. For example, a programming language and its compiler are usually a lot more polished than ones own definition schema.) The major benefit of code generation isn’t necessarily the productivity boost you get when writing the code but of the benefit of keeping your definitions in one place when each definition may lead to multiple classes and interactions.

Did you actually read the article before you commented, or did you just skim over it? :p

Did you think about this article before you wrote it?