This post originated from an RSS feed registered with Java Buzz by Norman Richards. Original Post: Don't generate code if you can't automate the process Feed Title: Orb [norman richards] Feed URL: http://members.capmac.org/~orb/blog.cgi/tech/java?flav=rss Feed Description: Monkey number 312,978,199 Latest Java Buzz Posts Latest Java Buzz Posts by Norman Richards Latest Posts From Orb [norman richards]

I am a big believer in code generation. We use everything from parser generators to JAXB to XDoclet. (shameless plug) I definitely prefer generating code to writing code by hand, but I never like to use code generation that can't be automated. Based on my experiences with the in-house code generation system I worked on at my former company, which generated code using scripts run inside of rational rose, I came up with two very important rules of code generation.

• Never check generated files into the repository
• Never generate code using a tool that can't be automated

Like your .class files, generated source files are a temporary byproduct of the build and should never ever be put in the source repository. Code generation should always be part of the normal build process. If your code generation tools are expensive propietary beasts that are too expensive or inflexible to use in your build process, throw them out.

Last week at work we made changes to our database schema files. Unknown to us, the DB guys decided to start using a database tool that generates SQL DDL from a proprietary model. The problem here is (besides not telling us) is that the SQL files are checked into the repository. The changes we made to the files were overwritten the next time they generated. It was a disaster. Of course, the application is so big and proprietary that there is no chance that we could apply the SQL generation as part of the build process, leaving us stuck.

Since I'm not a relational database GURU, I don't want to tell a database guy what process to use. But it is clearly a broken process. Changes can get lost. The input (model) and output (SQL file) are kept in sync only by human intervention.

As a general rule: don't use proprietary generators that don't support round tripping. If the code generator isn't free, you probably won't be able to use it as part of each developer build. Your licensing costs would go through the roof. Even if they didn't, the tool probably isn't going to be easily run from an ant build file. Unless your tool supports round tripping, you will have to check the code generation inputs AND outputs into the repository, which can be disastrous. With round trip support, your code generation tool can use the output file as the input source, in which case keeping the input and output in sync is a non-issue. But in that case, you've got nothing more than a very helpful IDE.