This is going to be the first in a series of items about Code Generation, automatically
generating your code. I have posted a couple of times previously on this topic,
but I thought a series of posts would be useful, so here is the first.
The Last One
I remember back in the 80s a UK company built a program
called ‘The Last One’,
its premise being that it was the last computer program because it would write
every program from thereon after. Now, after you have picked yourself up off of
the floor and stopped laughing, think about it somewhat objectively. Remember,
this was in the days of largely batch programs, they started at the beginning,
went through a file of instructions or updates, and reacted to each item
encountered. As such, with some very clear rules, it shouldn’t be too hard to
write a program to read those rules and then process the data files according
to those rules. Of course, it would all soon get messy, the types of rules are
infinite, and the types of data is also infinite, so some severe constraints
would have to be imposed, but wouldn’t a program that can handle multiple
applications, even if those applications have to adapt somewhat to that
program, be beneficial (of course, you could say this is exactly the same as
the SAP paradigm, but please, let’s
not talk about SAP when I am feeling good). Event driven applications add a
whole new, more difficult dimension of course, but still…
I am a great fan of code generation, using it frequently,
and always look for further opportunities to use it. Why do I think it is so
good? There are many reasons:
is reduced, make a small change and rerun and all code affected by that
change will be re-generated
quality is improved, all changes are re-generated, no need to remember
what needs changing
work is done in the more critical and interesting areas, in analysis and
To me that third point is the most important. Code
generation makes you think about the application requirements and how they should be implemented, something you should do by right, but something that
cannot be avoided or done half-heartedly when using code generation. As the design is so
critical, and as I find it more interesting than cutting code, this suits me
The greatest exponent of code generation that I am aware of
is Kathleen Dollard.
Her book, Code
Generation in Microsft .NET, is the definitive work on the subject, a
remarkably comprehensive work that provide end-to-end solutions using
XSLT-based code generation based upon a series of templates. As she says … Code generation will turbo-charge your
development cycles by offering speed, reusability, agility, and consistency.
Whilst this is a remarkable piece of work, I think that many
might find it daunting, even off-putting. The solution is comprehensive, but it
is based upon .NET and XML, and dare I say, can even been too purist for the
tyros amongst us. For this reason, I will address code generation from a much
simpler starting point, show how you can use code generation today using Excel,
and build upon it over the next few weeks,
Excel & Code Generation
What I have described so far are full-blown applications,
with their attendant complexity, which might discourage you from going any
further. But let’s step back a bit, and
think about ways in which we can generate code in small doses. Later items will
go further, but we can show immediate benefits. In these examples, we will use
Excel as the code generating engine. Excel is a superb tool for this, as it is
with so many other things, with the grid for our data input, and VBA to handle
any complex code generating algorithms.
You may not be aware of it, but maybe you are already using
Excel to do code generation. If you ever have a list in Excel, and use formulas
and functions to create some more descriptive text that you cut and paste into
a code module, that is a simple form of code generation.
Let’s take a simple example. I use class modules a lot, and
I find that creating properties is a pain, you need to define a private
variable where the actual value is stored, and then Get and Let properties so
that the property can be read from and written to in the class (that is assuming two
things, your property is read/write, they may not all be so; that you don’t
use Public variables for read/write properties – I don’t, I always declare Get
Using code generation, all we need are two pieces of
information, the property name and its data type. If we want to cater for some
properties being read only, we need a third denoting the access mode.
So, we can create a spreadsheet with 3 columns
column A - property name – free format text
column B - data type – Long, Double, String,
Boolean, Range (should suffice for now) – an ideal candidate for a data
- access mode – R, W, or RW – again another dv list
It would be wise to add a fourth, column D, derived column,
that takes the property name and replaces any spaces with _, and removes any
special characters, as this will be used in the class.
With a few simple formulae, we can easily generate all 3
elements of the property that the class needs,
="Private m_"&D2&" As "&D2
"Public Property Get "&$D2&"() As "
" "&$D2&" =
"Public Property Let "&$D2&"() As "
" m_ "&$D2&" =
"Public Property Let "&$D2&"(ByVal val As "
" m_"&$D2&" =
That is all there is to it. Create a list of properties with
their attributes, and Excel generates the class code for you, all you need to
do is cut and paste it into the class module.
Next time, we will show how to use VBA to write back this
data into the class code, after all, one of the primary aims of code generation
is to save us from the boring bits. We will also look at a slightly more complex generation.
RSS subscribers, this code is attached.