4

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!

|improve this question
  • 1
    see On discussions and why they don't make good questions – gnat Feb 16 '18 at 9:51
  • 1
    Code generation can be immensely useful, but I agree with your assessment that it is an antipattern for the scenario you are describing. The test program should simply be parametrized so that a single binary can run the different scenarios based on input arguments or options. – tripleee Feb 16 '18 at 9:51
  • Obligatory Raymond's recent post on the subject. – Tibo Feb 16 '18 at 9:57
  • 3
    I feel this is too broad or imprecise to answer. What does "variations of an existing program" mean? Is it variations which could just as well be configuration settings or is it something more complex? Obviously you should not use code generation if the same objective can be achieved using simpler means, but it is not clear if this is the case here. – JacquesB Feb 16 '18 at 10:19
  • Related: softwareengineering.stackexchange.com/q/339166/20756 – Blrfl Feb 16 '18 at 11:41
3

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.

|improve this 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.

|improve this answer
2

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.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.