Code generation is not a new concept. It has been around since the first lazy, err, smart coder realized that Hello World was the foundation of Hello World Too. I’m sure they figured they had written the code twice already and the third iteration is undoubtedly around the corner so they felt somewhat obligated to automate the process.
I’ve had the opportunity to see code generation in action. I’ve seen CodeSmith leveraged to the extreme — with a single click, a completely functional three-tiered application could be built before my very eyes. It is like magic. It is super-impressive and I commend anyone willing to put time into a building the code generators because they are awesome. And there are many advantages to auto-generating code:
- Code consistency
- Stable, tested and bug-free code which “works first time”
- Produced very quickly
- Easily updatable
- Programmers are free to concentrate on the areas of development that deserve their brainpower
- Increased productivity
- Learning aid — If the generated code is well written and consistent, programmers are more likely to copy the style of this code and learn from it
Does code generation make good sense to me? After all, I use it all the time. (Kind of.) You see, I tend to refactor my code and compile reusable libraries with common functions. I have templates for building custom classes and collection. I hardly ever write a routine without consulting my previous work (or the work of others) and I can’t remember the last time I started a project from scratch. I alway begin with an existing, similar project and then modify it for my needs.
As you can tell, I am a proponent of code reuse. I believe in patterns and I have no dream of reinventing the wheel. With this said, I am not a fan of code generation. Is there something wrong with me? Well, here are the disadvantages to code generation. You decide.
- A code generator must be written and tested thoroughly before code can be generated. This task time and effort and it adds some risk since you can’t get the “real” project out the door unless the generator is production-ready.
- Code generators really only work for specific applications with specific use cases. Code generators are best suited for admin-type applications which entail no business logic. If your application is nothing but CRUD then code-gen might be right for you.
- There will always be some code that needs to be hand-crafted. If the code generator doesn’t allow you to “support” hand-crafted code, you’re in a tough spot.
- Most code generators work off of an existing database schema. In most cases, a well formed databases (i.e. specific primary and foreign key names, normalization, etc) is required and generators generally do not cope well with databases that have special, “unique” design features. In addition, I don’t believe business objects should exactly mirror the associated database objects. For these reasons, code generators tend to lead to bad system designs.
- Code generation leads to poor performance. This one is obvious, right?
- Generated code is difficult to maintain. I should be really clear on this point. Without a firm, working knowledge of the code generation tool itself, the code is difficult to maintain. Unfortunately, there is little guarantee that the original author of the code is going to be the developer slated for maintenance.
It isn’t that I wish to be a modern-day John Henry. Simply, I believe code generators have their place and it’s not in my toolbox (except for really simple cases.)
Have you checked out SubSonic? It gets around several of the downsides you pointed out:
-Supports handcrafted code very well.
-Supports schema changes very well since a rebuild of the project triggers a rebuild of the DAL.
-Not difficult to maintain since there are no source code artifacts.
The rest are points I’d be interested in hearing you elaborate, and not just because we’ve spent hours arguing about code generation over the years:
-Someone needs to write the code generator… why is that a problem for you? Someone has written it, so…
-Only works for specific use cases – I agree for the “one click builds your app” kind, but CRUD code is pretty generic.
-Poor performance – I don’t think that’s a given. While wrapper code’s weight is negligible compared to the network overhead and database lookup time, generated code should actually more performant than data access code which calls into data access libraries. Instead of passing a bunch of variables to a function which maps the parameters to a database call, the generated data access code just makes the ADO call. There are cases where you just have to write a stored proc for complex queries, but in a lot of cases a good code generator which builds dynamic SQL will beat stored procedure based data access, since it can use more specific criteria which allow for better query performance over a general stored procedure. Codegen DAL’s like SubSonic are great because they have built in support for SP overrides when you need them, but you don’t have to write them unless perf testing calls for it.
Mr. Galloway, a lengthy comment such as yours deserves a response (or its own post perhaps.) Here’s what I will do. I’ll check out SubSonic and provide feedback. Who knows? Maybe I will never have to write a line of code again. I will also address your very valid comments and questions then. I wonder. Will our debate ever end?
[...] Ben Griswold09:53 am14 Comments8,950 Views Last month, I wrote Manual Code Generation, an article which shared, in my view, the pros and the cons of code generators. In this same [...]