Is Micro Code Generation Considered Harmful?

Question

I recently wrote a small tool to generate a class for each tier I hand write for the boring "forms over data" work where I spend almost 90% of my time (depressing I know) ... more on this as the economy improves ;)

My question is this - will using this tool instead of hand typing all this code from day to day actually hurt me as a developer? I feel like I will always be making changes to this tool and thus I "should" stay on top of the patterns used/ choices made/ etc... but some small part of me feels like I might loose my edge ... am I wrong?

Answer 1

You are most definitely not wrong. I use code generators anywhere I can - I currently use CodeSmith to create my DAO's by looking at the database.

What edge are you afraid of losing? In my mind going to code generation is actually giving you an edge.

Answer 2

If the tool can spit the code out without thought, then it probably saves you lots of thoughtless typing.

Writing the tool in the first place requires thinking, so I'd guess you'd be more "on the edge" maintaining and writing the tool.

Answer 3

Generate what you can. Code generation is one of the best tools I've picked up over the last 2 or 3 years. Typing the same code over and over (or copy and pasting it) is prone to error.

Answer 4

No. Why do you think IDE's are so popular. Imagine if all the people who use Visual Studio had to programmatically create the GUI's without help from the IDE, it'd be terrible. I would be willing to bet most people who use VisualStudio won't know how to manualy create the forms they're creating in the IDE. But there's nothing wrong with that.

Answer 5

I believe in code generation wherever possible to remove the rote tasks of programming. You will not lose your edge, you will probably become a better programmer because you will spend more time working on the important and interesting stuff.

BTW, your tool sounds interesting. Have you released it anywhere?

Answer 6

Spending less time doing something by having something/someone else do it, and more time researching better ways to do it will generally lead to doing it in a better way.

This doesn't have to just apply to programming....

Answer 7

That's good! Of course writing a tool to do all the job for you is impossible and wrong.

But automating repeatable tasks is always good - and sometimes writing specific types of code is repeatable.

It is even encouraged in the "Pragmatic Programmer" book.

Make sure that in the source control you have checked in a code generator and not its output (unless you have to modify the code later by hand)!

Answer 8

Code generation is fine as long as you understand what you are generating. Physicists use calculators because they understand the formulas they are automating and realize that their precious time is better spent on important tasks.

Answer 9

Larry Wall (of Perl fame) describes the three cardinal virtues of programming as Laziness, Impatience, and Hubris.

Congratulations! You have shown good laziness, in that you have identified some work you can pass off to an automated process and done so. (Bad laziness leads to cutting corners, procrastination, and generally postponing rather than eliminating work.) If you can successfully palm off some work onto another program, you are spending less time on annoying triviality and more on accomplishing things and learning.

Answer 10

Code generation is one of those invaluable DO:s that The Pragmatic Programmer advocates. I truly recommend that book. Here's a Pragmatic Programmer quick ref.

Answer 11

Its almost hypocritical not to code generate. Here we are automating all of these tasks that were traditionally done by hand... and yet many of us still hand crank all of our code, even if it can be easily generated.

Answer 12

My only experience with code generation is the macros of Common Lisp. They are used all the time. Everything that automats repetitive tasks is beneficial; that is what programming is about.

Read the story of Mac.

Answer 13

Imagine that each time you made a change to the tool and regenerated your code, that you made that design change by hand on all of your modules.

Since I've started generating code and gotten up to speed, I've found that I rarely get bugs in the generated code.

Answer 14

I find that writing code gen does help me learn the nuances of good architecture. You start seeing common patterns as opposed to a narrow view of your design. That said, don't use code gen as a substitute for good object-oriented code, and don't love your code gen so much you ignore new technologies. For example, if you're in .NET and are writing code-gen for data access, you'd better have a good excuse for not using Linq to SQL or NHibernate. Similarly, Dynamic Data can help in many forms-on-data scenarios. So, my advice: spike new stuff and code gen as needed.

Answer 15

Your code generator (at least in principle - I haven't looked at it myself) is The Right Thing, at least as far as it goes.

The next step would be to see whether you can, instead of generating all this redundant code, create a base class whose functionality matches the generated code and then derive your application code from it. Using inheritance rather than generation will allow you to benefit from improvements without needing to re-run the generator on all your projects. Perhaps more importantly, if you customize the generated code, the customizations would be lost if you re-run the generator, but customizations in a derived class will be preserved when the base class is changed.

Answer 16

My 2cents on code gen is that it is also critical for use in refactoring. I have found that partial classes and a good file comparison utility (Araxis or BeyondCompare) are essential.

Keep your generated code in one file and the custom Tweaks you made for that class in another file.

This practice will allow you to make those comprehensive framework changes implemented quickly and will also help you move to a new paradigm while easily being able to save your custom logic.

CodeSmith FTW!

While build servers are great to make sure all your code compiles, it doesn't address the differences in signatures with your stored procs or the like. If you routinely run the code gen you can more easily identify when those changes occur. A unit test will tell you the SP is wrong, code gen will tell you how to make it right.