I am going to discuss code generation over the next few posts for a couple of reasons.  One is that it is fundamental to the process of software industrialization and second, most programmers, that I know of anyway, dont like code generators, for a variety of reasons.

 

Maybe I should step back and give you my definition of what code generation means to me.  I am pretty sure we all have different ideas as to what this means.  Again, I will draw upon our analogy of AutoCAD.  Lets say I produce a drawing of a piston used for a race engine.  Once I have completed the drawing, I can then save the entire definition of that race piston in a universal file (i.e. DXF) format.  I can then take that piston file definition and feed it into a Computer Numerical Control (CNC) milling machine, which will produce (in our terms, code generate) the output, virtually 100% complete, save for a few finishing touches (i.e. polishing).

 

Thats the key.  I am required to produce a drawing that is 100% complete up front (i.e. design) before I can mill out the piston for my race engine.  When do we specify (i.e. design) anything that is 100% complete up front in the software world?  If I can design a software part or solution 100% up front, then I can code generate the solution, given the proper tools.

 

As a programmer, I would rather build the (code generator) tool that is going to produce the solution rather than the solution itself.  Why?  Because, in my experience, I know I am going to have to do it over and over again, just to get it right. 

 

Traditionally, I would incrementally iterate my way through the solution code several dozen (or even hundreds) of times which will ensure I have a POS by the time it is ready to deploy into production. 

 

So give me a design tool that allows me to draw and define what is supposed to be built (saved in a universal file format) and then I can build a code generator to read the design file and produce the solution output.  The effort is in the design and code generator, not in the solution code. It takes minutes to code generate a solution - every time.

 

Hey, I like to code as much as the next programmer.  But I am getting too old and tired and cant stay up to 4am for a week in a row when it comes down to crunch time for the final push to deliver I dont know what to the client.  If I am going to code anything, it is going to be a code generator.

 

If I build a code generator to read a file format that contains the definition (i.e. design) of a solution, then I can make changes to the design, just like when I want to change the shape or dimensions of the piston.  And if I am really smart, I would have a library of piston designs that I have accumulated over time, along with other reusable design pieces or parts (read: design patterns). 

 

We have several excellent books that document design patterns for virtually everything in software, including the infamous (Gamma et all), EAI design patterns, and in fact, if you type in software design patterns in Google, you get 18,900 hits.  So why dont we have code generators that take these design patterns as input?  Why not create a standardized library of design patterns that any IDE can read and produce the required output in your language of choice?  Oops, there is that word again, standard.

 

Next post will delve deeper into code generators.