Doom 3 Source Code: Beautiful

jones_supa writes "Shawn McGrath, the creator of the PS3 psychedelic puzzle-racing game Dyad, takes another look at Doom 3 source code. Instead of the technical reviews of Fabien Sanglard, Shawn zooms in with emphasis purely on coding style. He gives his insights in lexical analysis, const and rigid parameters, amount of comments, spacing, templates and method names. There is also some thoughts about coming to C++ with C background and without it. Even John Carmack himself popped in to give a comment."

Comments

Re:His Comment

[girlintraining]

One might suggest that every good programmer, if they spend enough time improving, eventually moves toward a more functional programming style.

Good programmers don't move towards any one style, they become familiar with all of them and use them when and where appropriate. Just like computer geeks. You find Linux one day, install it, then fall under the spell of believing this year will be the Year of the Linux Desktop. But after awhile, you reach the second plateau of understanding -- Linux is good for some things, but not everything. The third plateau is no longer caring which tool you use, as long as its the best tool for the job.

Most of His Admiration Is Not Technical

[Greyfox]

Most of his admiration appears to be issues of code formatting and lack of comments, not the technical design of the code. He started to lose me even before his rants on the ugliness of STL and boost libraries. Do the objects play well together? Is it easy to assemble them to accomplish tasks in sensible ways and with as little set-up as possible on the part of the user of the library? These were not questions I saw answered.

And a note on the relative evil of comments; bad or not, well placed comments have saved me an awful lot of time when taking on maintenance of code bases in the past. Most of the time they can't present a design document to you, or if they do it covers the design at the start of the project, a decade and a half earlier. Code is a method of communication between two programmers, but if the code doesn't suffice to illuminate the design the original programmer had in mind, I'd really appreciate a comment explaining his thoughts. Especially if the particular section of code is complex, and especially if I'm the guy writing it and end up being the guy maintaining it a couple years later.

Re:Not the best analysis

[Rhacman]

This is one of those topics of an almost religious fanatacism but I tend to agree. I want my braces to match in the same column and have an easier time looking at code with vertical spaces between blocks of related operations. Functions should still be short enough that they fit on a modern screen (with rare exceptions).

The whole concept of self-documenting code irks me too. Too often programmers use it as an excuse for not writing comments at all. Of course the code should be written clearly enough to the point where you don't need the comments to understand how the code will execute, but I don't think you should count on that as showing what and why that block of related operations is doing what it does. Comments can certainly be overused and underused and while commenting every single line is absurd in most cases, not commenting under the umbrella of "self-documenting" code can be detrimental as well.

Re:His Comment

[Rhacman]

As I get older, I gain more experience and hence believe that my opinions carry more weight. Since me and my close knit group of similarly aged friends agree with me it stands to reason that what I have come to believe now is in fact correct and that others who disagree with me are simply immature.

Re:Beautiful code but

[Anonymous Coward]

I did. No issues. Hint: The dark parts are supposed to be dark.