Do you use code generation tools?

Question

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.

Answer 1

We used to use CodeSmith to generate our NHibernate hbms, our entities, and a few other things. After a while we got sick of this flow so we ditched it.

The T4 generator is free and worth looking into for generation.

We still use the Castle CodeGenerator for MonoRail link generation.

Answer 2

We have an in-house built code generator that takes care of database access. One writes stored procedures and gets corresponding methods abstracted in a gateway class.

We also generate web services in order to properly interface with Flash -- i.e. handling exception in a sane manner.

Finally we have an exception generator that takes away the drudgery of exception best practices (tons of constructors, etc...)

Answer 3

At a previous employer, we had a home-grown VB.NET application that would turn an XML Schema Definition file (XSD) into a static C++ library. This made it much easier to work with C++ data types (bool, std::string, etc.), and all of the interesting XML code was hidden inside of these generated classes.

Answer 4

I started rolling my own generators (data access, sprocs, etc) back when I was doing classic asp work (circa 2001). I slowly moved to CodeSmith, since it was much easier to deal with. I was still primarily just generating all the Data Access layer type stuff (including sprocs) for my .NET code.

A couple years ago, I made the jump from Macro Code Generation (i.e. CodeSmith) to Micro Code Generation.

The difference is that with CodeSmith I was generating huge swaths of code for my app, all generic, and all at once. This became problematic for edge cases and regenerating when changing the source for the template (i.e. table structure). I also ran into cases where there was a high inventory of carrying code that I wasn't using, but was generated from my template. Did all those methods work? Maybe, maybe not. Going in and cleaning up the generated code would have been a huge amount of work (i.e. after more than a year on the same codebase).

Micro Code Generation, in contrast, allows me to generate exactly the classes I need, in exactly the right scenario I want. The primary tool I use to do this is ReSharper. The way I do this is by writing my unit tests before writing my production code. In that scenario, ReSharper uses my Unit Test as a template to auto-generate the skeleton for the production code. Then it's just a matter of filling in the blanks.

For Data Access, I'm no longer generating anything. I've found that a good O/R M replaces everything I used to put in my data access layer (i.e. NHibernate). Given that, I will never write or generate another data access layer in my life (I refuse to).

Plus, I get the benefits of having a large unit test suite, among other things

Answer 5

Yes, but we refer to them as interns.

Answer 6

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.

Answer 7

1. We use Code generators for Exceptions
2. Generating DAO for CRUD operations
3. use JAXB to genereate code
4. Use XDoclet to genereate EJB local/home interfaces
5. Use Velocity templates to generate documentation for business models
6. Use Apache Axis to generate WSDL stubs

Answer 8

I've used one to generate serializable data objects which could be reformed across different platforms (windows, linux, solaris, mac, bsd, etc). It was an in-house solution.

Answer 9

I met ActiveWriter a couple of months ago and it helped me very much, what I like is the flexibility of this approach, it generates partial classes that handle the data access issues and it lets me code the business part of the classes. I feel very satisfied cause saves me a lot of work, it´s pretty nice to change the schema, re-generate and go on.

Answer 10

I wrote a lovely tool in which the experts in the data format I'd written a parser for, could submit their own samples through a web form, look at the output, and tell me whether it was correct.

From that, a jUnit test would be generated. Lovely.

Except that not a single person bothered to use it, and I gathered no test cases whatseover.

Answer 11

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.

Answer 12

Since Fog Creek Software's in-house language, Wasabi, has compile-time code generators built in, we use them to automatically create the meat of our entity classes that map to database tables. So instead of writing a class with a dozen different properties and methods, we can just write:

<ActiveRecord("Kiwi")> _
Class CKiwi
End Class

and CKiwi will have Load(ix As Int32), Commit(), and fields/properties for every column defined in its underlying schema for the Kiwi table. It keeps us from having to have huge O/R M libraries, but still allows us to quickly add a table to our products.

Answer 13

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:

1. .NetTiers was bloated, and the code generated was enormous. I think code generation tools make it too easy to creature feep.

2. 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.

Answer 14

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.

Answer 15

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.

Answer 16

Home-brewed code generators work great for building unittest cases from end-user spreadsheets that contain examples of how it should work.

See Tooling to Build Test Cases for one example.

Answer 17

Not that we are working in the .net/web domain, but home-made code generations tools from various home-designed languages are a crucial part of our development tool chain. We have two major such tools (with grammars and parsers and formal definitions), and a host of minor one built on macros like m4 and perl. They all generate plain C in the end, which is natively compiled.

Domain-specific languages are one of the key tools for programmer productivity for any large-scale software endeavor in my experience. If you are building things like compilers, simulators, or other very complicated software with many recurring patterns that have no support at all in the basic languages (which typically means portable C and sometimes C++), code generating tools is the way to go. I view domain-specific languages as the next step in generalization: first you break out common computations into functions (or subroutines to be historical), then you break out common functions into templates or generics if such a facility is available, and then you break out even more commonality and repeating code into a full-blown custom language.

It is all about reducing the volume of code you actually write, and removing any form of tedious repetition and non-value-added code from the programming process. As soon as patterns repeat, apply a domain-specific language!

Answer 18

We use LLBLGen to produce our data access layer. You point the generator at the database your using, select which tables you want to use and it churns out the classes needed. It is all very quick and easy.

Answer 19

If interested in LLBLGEN, which is excellent, you might also evaluate subsonic. Maybe even see what Rob Conery has to say about any overlap or interaction between subsonic and t4.

Answer 20

I wrote and use an Xslt based code generation tool. http://perfectstorm.codeplex.com/

This uses a single root xml model to generate dal, procs, tables.