When to use code generation over flexible programming

Question

where I currently work, there is a team that uses code-generation to generate slight variations of a program. I find this a little bit awkward. I can imagine using code generators that produce complex code for stuff that is usable in different projects, but using a code generator just for variations of an existing program seems overkill to me.

I believe that code-generation is no good solution for this, because you create many versions of a certain program which in my eyes is hard to maintain. I believe you should try to use object-oriented programming (or another paradigm) to make one program flexible so it can handle all the required variations you need. This way you only have one version to maintain.

I was wondering what you think about it? When is using a code-generator really useful? Always? Or only for complex things?

I hope to hear some great thoughts about this, because to me it seems such an overkill.

Thanks!

Answer 1

I believe you should ... make one program flexible so it can handle all the required variations you need

How are you going to test that? Put in crude number terms, every time you add a "feature switch", you double the number of tests needed to perform regression testing every time you make a change. This can be an expensive maintenance headache.

Conversely, if you have multiple applications that are feature-specific and thus offer little or no flexibility, when you change one of them, you need only run a few tests on just that one application.

Conversely, lots of feature-specific applications can be a sales nightmare: "dear customer, please spend two hours filling out our 500 question survey, so we can pick the correct app from our pool of over a thousand tailored applications for your needs". No thanks. Just give me a generic solution and then configure it to my needs.

Neither is the correct solution. Each has pros and cons. So if your team is using code generation to create slight variations of an application and it is working, then great. Stick with it. If it's a genuine problem though, then maybe it needs changing. What does the rest of the team think? What do the testers think? Sales? Customers? You having a problem with it could mean the problem is with you, not the code generation process. If those others also have a problem though, then things need to change.

Answer 2

Code Generation isn't bad per se. After all that's what compilers do. Is c# bad because its a code generator for IL?

Whats bad is that code generation requires its own language or config to make it work.

If you are programming in code generation language, compiling to 'code' and compiling again to 'executable code' you have a whole extra step and potentially a new and unsupported language to deal with.

If that extra step is well supported and commonly used then you are probably fine. If its a cobbled together mass of powershell scripts bob from downstairs wrote as a work around for an internal problem in your company. Well, it has extra risks.

Answer 3

The basic question you need to ask yourself is: what are you going to maintain?

Supporting generated code is a nightmare, but supporting the code-generating scripts (code) isn't. What if you find a bug in one of the applications? Do you need to go through a pile of generated code to fix it in all your different applications or do you fix it in one place and just re-generate the code for the all the applications?

In some way of abstraction or another every programmer writes code-generating software and it's just about what you need to support. I write in a high-level language but I don't support assembly level maintenance.

So to answer your question: a code-generator is useful if you don't have to do maintenance on the generated code.