Dusting the cobwebs off some code old enough to qualify as an archeological artifact I discovered that the original developer (now long gone) had used a number of code generation tools for the DAL (data-access-layer) and interface. The code generation tools the developers had used proved stubbornly elusive and since I only had a few minor changes to make to the DAL and interface I foolishly decided to crack the seals on my archeological discovery and make the changes manually.
Any complaints you may ever had made anybody’s poorly documented code will pale in comparison to editing the dump truck of spaghetti that is generated code. What is most daunting about generated code is not that it’s terrible code (it usually isn’t) or that it’s poorly commented (I can live without comments) but just how massively verbose it can be. Generated code isn’t typically difficult to read, it’s just exhausting.
But I admit that my adventure into the bowels of generated code was unusual and most developers usually have access to the original code generation tools that were used. In this case the solution is easy. As long, of course, as no custom changes were made to the generated code after it was generated.
As soon as you make a single change to generated code you’ve struck a deal with cthulhu. You can either continue to modify the generated code manually — loosing many of the benefits of generating the code — or re-generate the code and re-implement any custom changes (if you know what they were).
Generated code sucks.
Unless it doesn’t. No other tool will save you more time or give you greater leverage then code generation (okay, maybe intellisense, but it’s close).
Code generation offers fantastic productivity increases, alleviates some of the more tedious programming chores (when’s the last time your wrote your own DAL from scratch?), and is the greatest invention since sliced bread (or intellisense). Eventually, however, the generated code will have to be updated or customized and cthulhu will appear to claim your soul.