Re: Hierarchy of code reuse by flexibility

Although I often find generators useful, code generation, at least the template sort, is little more than automated cut and paste. I don't consider either a very flexible mechanism at all.

modifications are not unrestrained. A template driven code generator can only substitute text where the template says it can. To modify the generated code beyond what is allowed by the templates, you have to revise the generator.
generated code can become a maintenance nightmare unless your generator is kind enough to tag its generated code with comments indicating versions of both the data source and the generator software. Otherwise, you have nothing to go on but date comparisons. However, date comparisons are only helpful if you have customized your build process to be aware of all your generators, often a lot of work. And even a customized build system won't help if you have no way of comparing the version of the current generator to the version that produced the generated code. Code generated by old and new versions of a generator aren't always compatible with each other or the current project requirements. But note: These issues largely disappear if code is always generated from data/source files as described by Tanktulus below. In that case, it is no riskier than generating .o files from .c files.
it can become even more of a maintenance problem if the generation process is incomplete and the generated code is hand modified. Unless the generator makes advanced provision for hand modifications, the generated code can't be regenerated. If the original generation process spewed out buggy code, you may be faced with hundreds or even thousands of lines of generated code that has to be found and hand modified.

The most flexible mechanism is well designed code that uses the right mix of programming paradigms (OO,procedural, functional, etc). Getting the right encapsulations and abstractions isn't always easy, but when it works, it really works and can grow and change quickly with your requirements. Solid design is more flexible because:

it avoids replication of bugs - all code is located in one place rather than copied all over.
it is easily composible
if bugs are found, the code can be fixed internally without needing to revise consumer code.
manual modifications can be made via subclassing or custom hooks, making it possible to regenerate even after extensive manual customization
support for polymorphism (via objects, dispatch tables, or switch statements) can be built in so that the code changes behavior based on its environment (operating system, server loads, end user preferences, etc)

So, I would actually put your list in reverse order:

Well designed libraries - capable of real time adaptation and localized modifications that do not affect manual customizations and consumer code.
Specific language constructs, e.g. switch statements, callbacks, inheritance - allows adaptive behavior for a narrow range of functionality
Code generation and cut and paste - one off static modifications.

Best, beth

Update: revised comments on maintenence+build process to incorporate Tanktulus's excellent description of "safe" code generation practices.

Comment on Re: Hierarchy of code reuse by flexibility

Replies are listed 'Best First'.
Re^2: Hierarchy of code reuse by flexibility by Tanktalus (Canon) on Feb 17, 2009 at 15:46 UTC
Having written some code generation in perl, generating C, Java, shell, among others, all from the same source data, I'm going to say that code generation and cut&paste don't belong together. Mind you, that may be because I have a fully-automated code generator (i.e., runs in the nightly builds) rather than a one-off code generation where we check in the generated code rather than the code generator. Making changes to one output instead of another is trivial. Adding data to the input is trivial (we store our input data in an XML-like format). If there's a different type of data that needs to be fed through from input to output, well, that depends on the flexibility of the code. In my case, I'd have to add probably about 3-6 lines of code to handle it one new type of data, because the underlying code base is simply that flexible. Tagging with comments is not needed - it's built every night. Getting the build system to recognise it is easy: make already can take arbitrary commands as a way of generating intermediate files (i.e., "C" code) - the fun part is labelling all the pre-reqs so make knows when to rebuild it. Oh, and hand modification of generated code is verbotten. Absolutely. If it's not a checked-in file, it can't be modified. Ever.	[reply]
Re^2: Hierarchy of code reuse by flexibility by tilly (Archbishop) on Feb 17, 2009 at 16:49 UTC
I absolutely agree that code generation bears a lot of risks. Particularly in a language like Perl that is not well designed for it. However I emphatically disagree about the potential returns. I suggested in the past that you read On Lisp, and I'm going to repeat it for the demonstrations of how powerful code generation can be. That said, code generation is a sledgehammer that should be swung carefully and precisely, if at all. (Personally at the moment I do lots of code generation of SQL, but none of Perl.)	[reply]
Re^3: Hierarchy of code reuse by flexibility by TGI (Parson) on Feb 17, 2009 at 19:11 UTC
I resort to code generation only when manually produced code will be (and often already has proven to be) harder to maintain and extend. TGI says moo	[reply]
Re^2: Hierarchy of code reuse by flexibility by zby (Vicar) on Feb 17, 2009 at 14:54 UTC
Hmm - I think I understand what you mean - and I mostly agree - but still I would say that I can make more changes in the code that is copied or generated then in libraries. Maybe I should have used some more precise words, maybe I should have called it 'modifiabillity' or something. But your reverse order really brings a more interesting question: if cut and paste and generation are really the worst of all techniques in this 'flexibility' measure - then why at all are they useful? Actually this hierarchy post was for me just a way of making sense of why and when to use code generation, cut and paste and libraries :)	[reply]