The Exceptional Beauty of Doom 3's Source Code

And don't forget the check the discussion about Carmack's comment from yesterday http://news.ycombinator.com/item?id=5055808 .

It's also worth checking out Sanglard's code review at http://fabiensanglard.net/doom3/index.php

I wouldn't call it exceptional beauty. Code can be beautiful, but most projects in gaming (or actually any other branch), just as the author of this article says, gets released under pressure. And yes, this pressure is more common and results in bad, smelly or messy code. However, quake and doom's source code were released/open sourced after the game was released. Maybe they cleaned it beforehand... This does not take away they have a strict procedure and quality control during the development. I have seen/read the code and it is well written!

I had to stop and think about that one myself. But it makes sence, at least if you emphasize on "hint at". When you wander though the source code, cascading the layers of abstraction, and jumping from place to place, it's nice that the code is somewhat bound to the same context.. in a way. It could be naming conventions, and using the same names for the same things consistently throughout the code. Another way to hint at the overall design is strict structure, e.g. layers: DAO-layer handles persistence, Business-layer handles business, Service-layer handles the interfaces to other parts of the application / other applications, etc. Naming the code-artifacts accordingly hints strongly at what it's doing.

Also code that is not directly dependant on the context (business domain) should be put in a special place, in Java that would be in util-methods "hidden" away in some common-package. This way it does not clutter the rest of the code, and allows for easier reuse.

The section on Minimal Templates is wrong on many points. There's usually no need to sacrifice genericness for readability; that's what typedefs are for. Also, C++11 now has foreach loops.