@tster said:
@djork said:Code generation is a good indicator of a flawed design. If your language of choice isn't malleable enough to avoid said generation, then you language is less than adequate for the task at hand. If the code generation is to work with an API (such as the one at my last job) then your API is poorly designed. I know it sounds like hyperbole, but it's true. Boilerplate == bad. Period.
That being said, the "design flaws" that the necesary code generation reveal are usually not major (except in certain circumstances, like the API at my last job). I don't mind Windows Forms code, but I wish that there was something simpler behind the scenes for laying out forms.
You couldn't be more wrong. Please read "The Pragmatic Programmer" for more info on generated code.
PS. I suppose you have never used a compiler?
I think you two are thinking of different types of code generators. And at least from the excerpt I read, the book seems to support both of you.
Wizards and code generators tend to come in two types (or at least opposite ends of a continuum). They type you seem to be thinking of is when you provide some intermediate form of input, and the generator spits out a black box that (hopefully) does what you want. Like you said, pretty much a compiler. In that case you're more or less creating a new language to handle something that's awkward in the original language. Examples would be IDL compilers, JSP pages, XML bindings, etc. In this case you're both right. The generator exposes a shortcoming in the original language, but the generator is a good thing since it let's you use a language that's more suitable to the task at hand.
The type of generator djork seems to be talking about is the type that generates boilerplate code (see many of the VC++ 6.0 MFC wizards). This type doesn't generate a black box you can plug and play. It generates code that is little better than automated cut & paste. The generated code is too mixed in with your "real" code to be a good black box. We make fun of that style of coding when it's done by hand, why should the wizard be excused? Too often you end up having to maintain this code yourself (because regenerating again is difficult/impossible, or the generator didn't account for all your needs, or regenerating it would destroy your customizations, etc.). If you don't understand what the generated code is doing (or if it's doing it in a sub-optimal way), it's going to cause you headaches down the line.
I agree with djork to a point, and I don't think your book really disagrees (once again based on the excerpt from the site). You wouldn't need the wizard/generator in the first place if your language/framework wasn't deficient in some sense (if it wasn't, it would be easier to just code what you want directly). A generator might be the best way to overcome that deficiency, but that doesn't change the fact that it exist.
Good wizards/generators will take take a form of input that's simpler than your original language and spit out a dependable black box. If that's not possible, they at least spit out boilerplate that's simple, understandable, and not much different from what you would have coded by hand anyway (e.g. getter/setter generation in Eclipse).
The problem is when a wizard/generator spits out a complex chunk of boilerplate that doesn't function as a black box. If you don't understand what that boiler plate is doing it's going to cause you headaches in the future. Sometimes worse than just writing the code yourself in the first place.