Do you use code-generation tools (aside from those used to generate proxies and from designers built-in to visual studio)?
What part(s) of your application do you generate?
Do you typically roll your own generator? If so, what type of generator do you write (asp templates, coddom etc.). If not, what 3rd party tools do you use?
I am currently working on a few different projects wich all use a custom code-generator that handles everything from generating the database structure, business entities, DAL, and BLL. I am curious about other peoples experiences are with these kinds of tools.
Code generation in the spirit of compilers can be great. Code generation in the spirit of "wizards" has uniformly turned out to be a bad idea.
We just started using Grails here in the office. Previously, we had a set of in-house JSF/Hibernate CRUD generation scripts.
... Grails wins. The code generation from Grails is very nice and can get you a CRUD app going in about 15 minutes, without actually putting the code in the code files!
Of course, it CAN generate the actual code into the code files, when you want to modify it. Most of the time, for regular CRUD, you can get away with just changing the views.
I have created a custom code generation framework that generates proxy classes for web services in several languages such as Java Script, Action Script, Java, C# and Objective C, I use no templates or tools just plain C# code that generates code with some helper classes, Code generation can really save a lot of time, but I think the generated code should be as simple as possible and should not be overused.
I create my own tools for some tasks. Its fun to do and even saves time in the long run. For very dull tasks, it even saves your sanity.
Like some others here, we have also created our own code generator (Inon Datamanager/Viewmanager) for data access, HTML form handling and certain business logic operations. A key to having this work well is to design it so you never have to touch or look at the generated code.
In this way, it almost does become part of the language - the language (Java in our case) is extended to include a domain model specification and a viewmodel, and then you just fill in custom business logic with real Java code.
This gives us the right tools to communicate with analysts and business users, while still having the power of Java to set up the details of underlying behaviour.
I'm in the philosophical camp that considers code generators to be "wrong", because they indicate something that should be made part of the language.
But it's been a big part of the Pragmatic Programmer's ethic to write code that writes code, and in practice code generation works well if the generated code is hidden by default. No matter how philosophically pure you want to be, the language will never evolve as fast as the problems you want to solve.
The code that gets generated when you build a Windows Form in Visual Studio comes to mind. You can look at the generated code if you want, but it's a better idea not to. Moving to a declarative language with WPF was superior, however, because it's cleaner and more reliable to manipulate declarative code programmatically than imperative code.
They should have done the same thing with LINQ-To-SQL classes. They need a declarative language for classes that just have properties and no custom behavior. It probably would make it easier to make those entity classes dynamic--changing automatically when the underlying database schema changes.
We tried using CodeSmith to generate .NetTiers classes for all the tables in our database, but ran into two issues:
.NetTiers was bloated, and the code generated was enormous. I think code generation tools make it too easy to creature feep.
Because the schema was being actively developed and revised, we had to regenerate a lot, too, and that ended up making it very difficult to keep everything in source control because all the files were being regenerated and replaced. I ended up being unsure if the generated code ought to be in source control at all.
The best place for code generation should be in the compiler or the build phase, not the design phase. When you use an anonymous type or method in C#, the compiler is doing code generation on the fly. If you generate code during the design phase, you get a chunk of stuff that must be regenerated every time the underlying parameters change.