Thursday, August 16, 2007

Writing code which writes code

Lately I have had some experience with writing code for some code generators or I could call it “doing Metaprogramming”. This was a new world for me and I must say that in the beginning I was pretty skeptical, but after some time I can really see significant benefits for the developer.

Very very often you have some code derived from some sort of metadata. This could be a database schema, xsd or a third thing. In my opinion you save tons of time writing a tool (if not already written) that generates code based on that metadata. Your overall maintenance burden will be lower and you have the freedom to change the metadata and just regenerate the code again. You will be better prepared for changes.

Frameworks like Hibernate do have tools for doing tasks like this. For example the “POJO Java code exporter” Ant task. If you for example rely on some home made persistence layer then the code generator properly also has be home made.

Having the code generator done all you have to do is “design” your next domain object. During the build you will get your domain class properly also a DAO class and maybe other application specific classes. The code is generated without you typing any line of code and the code will have the style like all the other domain classes generated.

Potentially errors in the DAO layer is fixed in one place – the code generator. This can give you the effect that either do everything work or else nothing is working :-)

Frameworks like Ruby On Rails also have built in code generation and I mentioned Hibernate above. If you have based your application on frameworks like this much of the code generator stuff is already given to you, but maybe it is not enough to suite your application?

Writing a code generator will initially take some time but depending on the application the development time should be compensated. You need to make the judgment – is it worth the effort?

Code generation is not for persistence layer only. A UI generator can also be worth the effort, but maybe a bit more complex depending on the demands for the different screen displays.

I would like to give a little example. Yesterday I needed to add some functionality to an application which uses code generators. The functionality involved the presentation layer and on any given screen display the possibility for adding a specific button (with functionality irrelevant for the example) should be available.

Adding this specific button to the screen display required a HTML form and some Javascript. With no code generators I as a developer would be forced to add this HTML form and the Javascript to every (in this case) JSP page where the button should be present.

I could optimize this a little with having the pain of writing a taglib, but again the taglib must be added to the page. With an extension to the code generator the required code is added when needed - end of story. The code is maintained in one place and no need for a developer to add the specific button functionality to a screen display. A person (maybe the customer) which understands the UI metadata can add the button to any screen display.

I am not saying that the first thing I will do on my next project is to start writing a code generator, but I will for sure try to spot areas where a code generator will be handy and save some development time on repetitive tasks...

7 comments:

Anonymous said...

It is indeed interesting stuff you write about.

You should read the pragmatic programmers book, if you havn't done it already.
They talk about some of the benefits of writing your own domain specific language or "programming close to the domain" as they call it.

If you concider writing your own domain-specific-language for your next project you could probably take a look at JavaCC

Ricky Clarkson said...

All us Java programmers are slowly rediscovering what Lisp programmers have known for decades - languages are meant to change as you use them.

Try out Lisp macros sometime. That's code generation without leaving the language, very powerful.

Anonymous said...

Have you got any thoughts on whether you like code generation at compile time or at runtime the best?

Personally, I hate code-generation at compile time but like it at runtime. Generating code as in generating actual source files that need to be compiled, has always seemed to clutter my builds up. And slow them down, not to mention.

Claus Myglegaard Vagner said...

@Jacob von Eyben:
I have to read that book...

@Tech Per:
I agree that code-generation can clutter up a build to the degreee that they become more complex and you need to be more deciplined in seperating the build of the diffrerent layers.

Of cource the build time will be higher if you have changed some metadata and need to generate the code again, but sometimes it can be better to let the developer wait in contrary to the end-user of the application (if you have runtime code generation) :-)

With the performance decrease in mind I would prefer a runtime code generation if it solves the problem, but I dont think the two methods are excluding each other. They can both be useful in different areas.

Anonymous said...

The source code generators usually result in a template or even just a stub for a given pattern based (but not always) on a parameter or two. I find them as good starting points, but hardly a "one-click-solution" to any problem of importance.

Thomas said...

Though I am generalizing now I think from a puristic viewpoint that if you need code generators you're using a too weak programming language. But I guess it's like the litteral programming thing, great in theory, impossible to implement... ;)

PS!
Ajax at the speed of light

Anonymous said...

Well said.