Jeremy D. Miller -- The Shade Tree Developer

I usually generate code to avoid wasting time writting stupid code. That means it has to be excluded from anykind of analisys tool (except profiling). More over, if the generator is not that good...you get uninteresting code stupidly written :-)

Jeremy,

Good thing you were not sitting up front :)

And the quote was closer to , what makes Subsonic's Generated Code better than code that I can generate using CodeSmith myself.

And the answer is because the Subsonic team has more expeprience with Data Access Code then I do.

But, I will have to see if resharper likes the code as much as I do...

The number of rules that strongly typed DataSets break in FXCop is kind of pitiful.

In VB, it also sets Option Strict Off at  the top of the file.

Tsk tsk,

Didn't Microsoft ever tell you not to open that code file?  Blind faith my friend, blind faith.  

Generated code can be pretty good it all depends on the code generation or template.

One way I've developed templates for both CodeSmith and SubSonic is to start by writing the class by hand and refining and refactoring it until I am very happy with it and then turn it into a template.

When revising it later, refactor the generated code then diff it against the non-refactored version and make the necessary changes to the template.

[)amien

Amern Damien.  Generated code is only as good as the original programmer who wrote the generator...

@Jeremy: somebody has to write the code. Organizations have good and bad coders, so if there is no generation you get a mix of good and bad code, and everyone spends time writing code. If an expert developer in an organization makes the generator, everybody gets code as good as his, and without even spending time writing it. If you later decide you want to change the code, you just change the generator -- rather than trying to write instructions to every coder to change their own code, and hoping they follow them.

Remember the move from assembler to 3GLs? The arguments are all basically the same, and code generation from Domain-Specific (Modeling) Languages only makes sense if you can ignore the generated code, because you trust the person who made the generator.

If you want to see some concrete cases, look at www.dsmforum.org. The key thing seems to be to make the modeling language and generator for a very narrow domain. This normally means making them internally, rather than buying them off-the-shelf -- we had enough of off-the-shelf generators in CASE and UML tools. When you have the freedom to change the modeling language and generator for YOUR needs, rather than begging some third party for changes, you can get the 5-10x increase in productivity that organizations like Nokia and Lucent have been enjoying for over a decade.

Of course, if the template sucks and the meta data is lacking, the generated code will suck as well, at least on the scale of suck used by the reader of the code.

So to get good code generated, you need to have good templates AND good meta-data. If either one of them (so a good template with sucky meta-data also gives bad results) is lacking in some area, you won't get stellar results.

That doesn't mean the concept of code generation sucks. the thing with code generation is that, IF the template and meta-data is OK, a code generator will beat any developer, simply because it won't make mistakes every X lines of code and won't get bored so it will take shortcuts nor will it get tired of the repetitive piles of goo it has to write.

I must say that I always find it a little funny that a developer declares code generation not that great a technique, so in other words: he himself is always capable of writing better code than a code generator can.

the thing is: that's a lie. You can't beat a code generator with proper templates and OK meta-data, simply because the code generator won't make errors.

But again: make no mistake: it is essential that the templates and meta-data are OK. this means that the templates have to be created from hand-written code, then the generated code has to be tested, profiled, checked for lame mistakes. This process has to be repeated till there are NO BUGS in the templates left and no lame lines of code left in the templates which make whinetools like fxcop throw up.

Code generators are just typing machines: they do the typing for you. If you look at them that way, there's no magic, they're just handy because who wants to type for weeks after weeks if a code generator can do that in a minute?

MS' internal code generator isn't that great, as it doesn't use templates, it uses the CodeDOM. This isn't a great decision because you can't alter the template to make it better.

Or you can lose the macro code generation (like CodeSmith) in favor of micro code generation (ala TDD and ReSharper)

NHibernate is pretty cleanly written (in OO terms), and there's no macro code generation there (so it can be done).

"NHibernate is pretty cleanly written (in OO terms), and there's no macro code generation there (so it can be done)."

Sure there is, at runtime. You don't see it, but it's there. Don't think POCO classes are persistable without runtime code gen. (or you have to fall back on lovely reflection... )

Ya know, I never bit at the code generation carrot and this just reenforces that notion in my mind.

I can see where it would be beneficial. You have thousands of lines of code to write and only enough man hours and developers to do half that.

The catch is in the corporate environment (doesn't apply to non-profit situations), is that where do you draw the line where you start to sacrifice readability and maintability to get something done quicker?

Frans, you mention that good generated code isn't worth it if you don't have good metadata and good templates then all is lost, well then in my book you have to pick your poison. Do you want to make sure your templates and metadata are inline, or do you want to write code for all the generic boiler plate code.

Or...you can take a ORM approach and use something like nhibernate or the such. Sure there is runtime code generation, but not a big cow flop that you have to constantly re-generate to accomodate for a new dataset.

Anyways, I've argued this point to death elsewhere already. Firing squad....Fire away!! =)

The quaility of auto generated code is only as good as the effort YOU are prepared to put into the template.

I guess most devs think because it's auto generated code they don't have to put to much effort into the template becuase more than likely it's going to be boilerplate code that does show off their amazing coding abilities :)

I'm interested what Frans means by 'meta data' in respect to templates?

As someone that has actually used SubSonic and looked at it's templates quite a bit I can say they are very clean, very solid templates mostly for one reason; they don't try to do everything for you.  The reason most generated code gets so ugly usually is the developer gets bored and starts adding poo in thinking, "oh,this will be neat, everyone needs caching like I do, and what a cool provider model I think I'll just jam in here."

You know how you should read other people's code to learn new things?  I actually *enjoy* reading SubSonic generated code, unlike netTiers that about makes me cry or even .NET Web Controls which I consider an unholy bastardization.  Server-side controls are IMO pure evil.  If you can't write the html yourself you probably shouldn't be writing web apps.

Anyway, it's like anything else in programming, it's rarely the technology at fault, it's the human behind it.  Generated code isn't ugly because it's generated, it's because the person creating the templates got it wrong.  Saying generated code is bad is just as silly as saying it's good.

Jeremy,

"Not to change the subject, but that's exactly why I'm dubious about Software Factories and any kind of large scale code generation"

Well, if you consider that most non-generated code written by plain developers sucks, chances are that most generated code will suck too.  But its not a guarantee.  You can certainly pick up codesmith or mygeneration and create templates that DO in fact generate clean code, because the templates are written by YOU (or a Frans said, by someone else who can write readable code.)

This is way off topic, but one thing noone seems to consider about code-generation...the very fact that you have to have a seperate template and code generation language says something about the strongly typed languages we use: C#, Java, VB.NET etc.  Languages like Ruby and Lisp get this dynamic generation without going to a separate tool and template language.  You can modify a class at runtime in Ruby or Lisp (from what i've heard) pretty easily in the native language.  Code-generation is really just another way of writing an algorithim.  If we need programs that write other programs, shouldn't our languages do that natively without going to something clunky like reflection?

I love my intellisense and compile time checks as much as the next strongly typed developer, but part of me thinks that code-generation is a sign we're reaching the limits of our language of choice.