The Exceptional Beauty of Doom 3's Source Code

The most tantalizing idea here was that "Local code should explain, or at least hint at the overall system design." I was disappointed that there was no further reference to it after the introduction.<p>In the end, much of the article was yet another articulation of syntactic preferences.

And don't forget the check the discussion about Carmack's comment from yesterday <a href="http://news.ycombinator.com/item?id=5055808" rel="nofollow">http://news.ycombinator.com/item?id=5055808</a> .

More or less dupe <a href="http://news.ycombinator.com/item?id=5055808" rel="nofollow">http://news.ycombinator.com/item?id=5055808</a><p>edit: spelling

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!

It's also worth checking out Sanglard's code review at <a href="http://fabiensanglard.net/doom3/index.php" rel="nofollow">http://fabiensanglard.net/doom3/index.php</a>

Could some one explain the preference for printf over streams?<p>I find streams much easier to maintain since there is only one list instead of printf's two. I find Niether is really good at large string interpolation jobs, but streams seem to scale better to me.

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.

How 'bout that.<p>I thought this would have been submitted days ago.