Some code is more equal than others

Originally posted to Shawn Hargreaves Blog on MSDN, Friday, March 23, 2007

Once upon a time I used to program in Perl. There, I admitted it! My dirty secret is out :-)

Perl is an odd language, and there are plenty of things not to like about it, but one thing I did like is how it is designed to let you choose your own coding style based on whatever problem you are trying to solve. Larry Wall, the creator of Perl, put this rather nicely:

[you can] choose what to optimize for, whether that's computer speed or programmer speed, verbosity or conciseness, readability or maintainability or reusability or portability or learnability or teachability. You can even optimize for obscurity, if you're entering an Obfuscated Perl contest.

I think Perl took this philosophy too far, but the basic principle of choosing what to optimize for is useful for all the code I write. I find myself doing several different kinds of programming:

Prototype code, to learn a new technology or find out whether a new idea will actually work.

Internal utilities, for instance a script that deploys new framework builds onto my Xbox, or the unit tests that make sure my code really does what I think it should.

Shipping product code, for instance the games I wrote in my previous life.

Framework APIs, such as the work I did on XNA or Allegro.

Sample code, shipped in source form for other people to learn from.

These styles of programming are obviously very different. I can write prototype code maybe twice as fast as an internal utility, while product or framework code is an order of magnitude slower.

Once you start thinking about these differences, an interesting question occurs. How can I spend less time writing product code? How can I write low-overhead internal utilities that will somehow automate or reduce the amount of slower product code development?

This is one of the reasons I like having a content pipeline that separates build time data processing from my runtime game code. The more computations I can move from my game into a custom content processor, the less product code I have to write. Processors are internal utilities that only ever have to run on my computer, so I can get away with all kinds of shortcuts that would never be acceptable if I was doing this processing as part of my shipping game code.

Blog index   -   Back to my homepage