Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Doom 3 Source Code: Beautiful

timothy posted about a year ago | from the but-deadly dept.

Programming 399

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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


Solaris Code (1)

Anonymous Coward | about a year ago | (#42593563)

..also nice.

Re:Solaris Code (1)

Anonymous Coward | about a year ago | (#42593911)

Yep, almost as nice as FreeBSDs code.

Re:Solaris Code (5, Interesting)

phantomfive (622387) | about a year ago | (#42594223)

Write a review of Solaris code, and it'll probably get posted on Slashdot, too. I for one would be interested in reading that.

Beautiful code but (5, Funny)

discord5 (798235) | about a year ago | (#42593621)

  • It might be beautiful code, but 90% of it just renders a black screen in a horribly inefficient way.
  • For best effect the source code should be read in the dark with a flashlight in your hand.
  • // TODO : add the code for the lightswitch in this class

I'll be here all week.

Re:Beautiful code but (4, Funny)

djlemma (1053860) | about a year ago | (#42593719)

Don't forget that you can't use your keyboard and your flashlight at the same time...

Re:Beautiful code but (0, Offtopic)

dpilot (134227) | about a year ago | (#42594237)

Oh come on... The duct-tape patch is old news.

Re:Beautiful code but (1)

Anonymous Coward | about a year ago | (#42594643)

It's a fair dig if you had to play the whole damned game through wtihout the duct tape patch.

Re:Beautiful code but (5, Insightful)

Anonymous Coward | about a year ago | (#42594795)

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

Re:Beautiful code but (1)

Anonymous Coward | about a year ago | (#42593733)

maybe you should buy display that can do proper black levels...

Limiting your market (4, Insightful)

tepples (727027) | about a year ago | (#42593801)

A developer needs to make an application for the hardware people have, not the hardware he wishes people had. Otherwise, he's likely to end up limiting his market to a subset that's not big enough to turn a profit.

Re:Limiting your market (0)

Anonymous Coward | about a year ago | (#42593987)

yeah people used to have CRT:s that are known for good blacklevels but upon retardation they insist buying shitty 6-bit tn panels that were not able to do blacks at all or brights and then your saying that we should just degenerate all software to meet retards needs... yeah it might be good thing for while in terms of profit but eventually you'll kill the whole platform&industry because its so big hassle to buy a) decent product b) people think its platforms fault...

Re:Limiting your market (4, Insightful)

Uhyve (2143088) | about a year ago | (#42594063)

Yeah.... No. Developers aren't going to drop half a colour palette because you're too lazy to look into which TVs don't suck.

Re:Limiting your market (1)

tepples (727027) | about a year ago | (#42594143)

Major developers already tend to consolize [pcgamingstandards.com] their games, dropping model detail, texture detail, shader complexity, and complexity of player actions because a lot of gamers are too cheap to buy an up-to-date gaming PC rather than one of the current consoles.

Re:Beautiful code but (2)

gl4ss (559668) | about a year ago | (#42594095)

maybe you should buy display that can do proper black levels...

I don't think you played Doom 3. doesn't matter how much you up the gamma the black areas are still black with some areas less black where you can sort of see where the path goes.

the re-release has a flashlight attached to player... doom3 has a great engine and is hampered by shitty, shitty, shitty level design. for a proper game done with the engine see quake 4.

Re:Beautiful code but (1)

X0563511 (793323) | about a year ago | (#42594891)

I found it to be stressful, in a fun way, having to manage that clunky shitty flashlight like that. I'm sorry not everyone thinks that kind of thing is fun.

Re:Beautiful code but (0)

Anonymous Coward | about a year ago | (#42593789)

You have not played the BFG Edition, have you?

Re:Beautiful code but (5, Funny)

IcyNeko (891749) | about a year ago | (#42593849)

John Carmack: The Kanye West of Video Game Programming.

"Imma let you finish your Dragonborn DLC in a minute, but DOOM 3 has the cleanest source code of all time. OF ALL TIME!"

Re:Beautiful code but (2)

PPalmgren (1009823) | about a year ago | (#42593907)

In retrospect, I think timing is what hurt Doom 3 more than the darkness. Doom 3 was released at the same time LCD monitors started to take off, problem was that LCD black levels at the time were horse manure. I saw my friend playing it on his and it looked awful. The unfixed drawbacks of new tech hurt the game's reception among many.

Re:Beautiful code but (5, Funny)

Stormwatch (703920) | about a year ago | (#42593941)

// TODO : rehire Romero, Petersen, Hall, McGee, Prince.

There, fixed. The engine may be fantastic, but Doom 3 is a horrible game that can't hold a candle to the previous titles. Or at least it can't hold a candle and a gun at the same time.

Re:Beautiful code but (1)

Joehonkie (665142) | about a year ago | (#42594065)

Yes, Romero and McGee have a GREAT track record these days...

Re:Beautiful code but (2)

Stormwatch (703920) | about a year ago | (#42594195)

Daikatana and Alice were far from perfect, but they're still more enjoyable than Doom 3.

Re:Beautiful code but (0)

Anonymous Coward | about a year ago | (#42594555)

Pretty sure both sales and critics (on average) disagree with that.

Re:Beautiful code but (2)

gman003 (1693318) | about a year ago | (#42594901)

Did you actually play Daikatana?

I did. I quit before the end of the first level. An absolutely horrid game. Doom 3 I at least lasted about 30% of the way through the game before throwing in the towel. It was mostly the repetition, the constant stuff jumping at you. It's a very fatiguing game - I could probably make it through it if I took breaks to play other games every so often.

Re:Beautiful code but (4, Insightful)

X0563511 (793323) | about a year ago | (#42594923)

Speak for yourself. I thoroughly enjoyed Doom 3. Quake 4 as well. I actually modded in more self-shadowing and flashlight shadows into Quake 4 - wasn't dark enough.

Re:Beautiful code but (0)

Anonymous Coward | about a year ago | (#42593995)

Funny, but true. I remember spending hours tweaking the config file to get the frame-rates somewhere near acceptable. Even on modern hardware, it lags and jitters unacceptably. Beautiful code it may have been... but optimized for actual functionality, it was not.

Not the best analysis (3, Interesting)

hugortega (721079) | about a year ago | (#42593767)

It's just a personal point of view about coding style... some things like vertical spacing using the braces (at the section "Doom does not waste vertical space") are just the opposite of a readable source code (just in my opinion, of course, as someone that makes a lot of source code reviews of other people)

Re:Not the best analysis (5, Informative)

gbjbaanb (229885) | about a year ago | (#42593975)

the concept of the bracket placement there is to emphasise indentation over bracketing. Once you "get" the view of it, it becomes a nice thing to look at, similar to python code.

I don't use it nowadays (too many coding standards that are written for the bracketing-style) but I appreciated it when I did. There's nothing wrong with the style, so I hope that you pass any code you review written in this style and focus on the important parts like readability of the code, good naming, commenting and the like rather than subjective opinions.

Re:Not the best analysis (5, Insightful)

Rhacman (1528815) | about a year ago | (#42594305)

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:Not the best analysis (1)

Anonymous Coward | about a year ago | (#42594365)

Agreed on the vertical space. His justification of removing vertical space is that you can read more on a monitor, and therefore see how the function your reading fits in its surroundings - this is bogus for anything but trivial code, where the definition of a function and its uses aren't going to fit on one screen height.

Re:Not the best analysis (1)

Fallingcow (213461) | about a year ago | (#42594531)

Yeah, I saw those examples in reverse-order as far as readability. I usually agree about including optional braces, but in that example the bracketless one was very eye-friendly IMO, while the one with minimal line breaks seemed like it would be headache inducing if I had to look at that kind of thing all day.

His Comment (5, Informative)

phantomfive (622387) | about a year ago | (#42593805)

Here is what John Carmack wrote:

In some ways, I still think the Quake 3 code is cleaner, as a final evolution of my C style, rather than the first iteration of my C++ style, but it may be more of a factor of the smaller total line count, or the fact that I haven’t really looked at it in a decade. I do think "good C++" is better than "good C" from a readability standpoint, all other things being equal.

I sort of meandered into C++ with Doom 3 – I was an experienced C programmer with OOP background from NeXT’s Objective-C, so I just started writing C++ without any proper study of usage and idiom. In retrospect, I very much wish I had read Effective C++ and some other material. A couple of the other programmers had prior C++ experience, but they mostly followed the stylistic choices I set.

I mistrusted templates for many years, and still use them with restraint, but I eventually decided I liked strong typing more than I disliked weird code in headers. The debate on STL is still ongoing here at Id, and gets a little spirited. Back when Doom 3 was started, using STL was almost certainly not a good call, but reasonable arguments can be made for it today, even in games.

I am a full const nazi nowadays, and I chide any programmer that doesn’t const every variable and parameter that can be.

The major evolution that is still going on for me is towards a more functional programming style, which involves unlearning a lot of old habits, and backing away from some OOP directions.

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

Re:His Comment (4, Funny)

MobyDisk (75490) | about a year ago | (#42594013)

You remind me of my mom, who ends every political debate by stating that as people become older and wiser they tend toward being Republicans.

Re:His Comment (2, Funny)

Anonymous Coward | about a year ago | (#42594119)

Republicans implemented in emacs lisp.

Reply with (3, Funny)

Anonymous Coward | about a year ago | (#42594209)

"Things seem wiser when you become older and senile"

Re:His Comment (0)

caywen (942955) | about a year ago | (#42594307)

Yes, older, wiser, greedier, selfish, and judgemental.

Re:His Comment (0)

Anonymous Coward | about a year ago | (#42594819)

Because that certainly doesn't fit the model of a Democrat...

Re:His Comment (1)

Anonymous Coward | about a year ago | (#42594315)

Tell her she is confusing wisdom with senility.
But then again, when asked, I reply "I'm seventy-years young"...

Re:His Comment (0)

Anonymous Coward | about a year ago | (#42594355)

So what you're saying is that your Mom is pretty smart? Or just that old people realize that they may not die before they actually have to deal with the long term consequences of their actions.

Re:His Comment (5, Insightful)

Rhacman (1528815) | about a year ago | (#42594479)

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:His Comment (5, Insightful)

girlintraining (1395911) | about a year ago | (#42594083)

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.

Re:His Comment (4, Interesting)

jez9999 (618189) | about a year ago | (#42594349)

Yet the fourth plateau is the realization that if one vendor becomes extremely powerful, it tends to create huge barriers of entry for others and so your choice is reduced, sometimes drastically, and therefore it can be a good idea to just arbitrarily support competition even if what everyone uses is good enough right now.

Re:His Comment (2)

chispito (1870390) | about a year ago | (#42594703)

Yet the fourth plateau is the realization that if one vendor becomes extremely powerful, it tends to create huge barriers of entry for others and so your choice is reduced, sometimes drastically, and therefore it can be a good idea to just arbitrarily support competition even if what everyone uses is good enough right now.

Also, divided government.

Re:His Comment (3, Interesting)

phantomfive (622387) | about a year ago | (#42594503)

It actually follows a predictable patter (YMMV no warranty implied etc):

1) A programmer discovers scripting languages and loves them, because they are so easy to write. Which is true.
2) The programmer discovers OOP, and realizes it makes code so much easier to read. Which is also true.
3) Then the programmer discovers functional programming, and realizes it makes it so much easier to avoid bugs. Which is also true.

You might say Python tries to combine all three of these features, which is true, though I offer no opinion on how well it does.

Re:His Comment (1)

El_Muerte_TDS (592157) | about a year ago | (#42594477)

The major evolution that is still going on for me is towards a more functional programming style, which involves unlearning a lot of old habits, and backing away from some OOP directions.

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

That is more or less the same conclusion/train of thought Epic Games' Tim Sweeny had in 2005: http://dl.acm.org/citation.cfm?id=1111037.1111061 [acm.org] (note: slides of the talk can be found on the internet).

Else ifs - yuck (-1)

blahbooboo (839709) | about a year ago | (#42593877)

I know some situations else-if statements are necessary, but my understanding is that case statements are far faster. So this "beautiful code" perhaps should have focused on code that could process faster as if this is one mistake in efficiency, wonder what else ID missed?

Re:Else ifs - yuck (2)

ledow (319597) | about a year ago | (#42594001)

In any properly written compiler, both are pretty equivalent and in almost all cases there wouldn't even be a difference in generated assembler, let alone performance.

case is basically a lot of else-if's, and else-if's are basically a single-path case.

Re:Else ifs - yuck (0)

Anonymous Coward | about a year ago | (#42594187)

Oh, another moron.

Case statements can be optimized using jump tables.

Re:Else ifs - yuck (0)

Anonymous Coward | about a year ago | (#42594361)

Under equivalent circumstances, the same could be done with an if/else-if chain. And jump tables aren't always faster.

Re:Else ifs - yuck (3, Insightful)

blueg3 (192743) | about a year ago | (#42594851)

Case statements can be optimized using jump tables.

Any semantically-equivalent code (that is, two instances of code that "does the same thing") can be optimized to the same set of instructions. It's just a matter of whether or not the optimizer can figure that out.

Re:Else ifs - yuck (0)

Anonymous Coward | about a year ago | (#42594293)

Not neccessarily. If the processor architecture/assembly language supports jumps/branches relative to the program counter, and the case statements are sequential values, you can setup a jump table. That way, you jump by on offset based on your case value, which leads directly to a second jump statement to the relevant batch of code. This makes it so you don't have to check every condition until you get to the one you need.

It's been awhile since I've played with it, but the trick works in x86, and a good compiler will use it. However, I was never able to find an equivalent trick for Power/PowerPC.

Re:Else ifs - yuck (1)

ShanghaiBill (739463) | about a year ago | (#42594757)

there wouldn't even be a difference in generated assembler, let alone performance.

Not necessarily. If there are enough cases, a switch statement will be faster because the compiler will create a jump table. But an if-else chain will be faster if the programmer knows (and the compiler doesn't know) which cases are more common, and tests for the most common cases first. But in most cases it doesn't matter. So use whatever makes the code more readable.

Re:Else ifs - yuck (2)

willy_me (212994) | about a year ago | (#42594903)

As others have pointed out, case statements utilize jump tables for better performance. It is noteworthy because depending on the elements within a case statement, it isn't always efficient. If you're testing an enum then it will be great as the resulting jump table will be small. If you're testing an int value, the resulting jump table could be huge - so you have to be careful.

Depending on what you're programming for (embedded systems?) the choice of if to use a case or if-else statement is not always obvious. You have to look at each case individually. But for desktop programming, one should use the syntax that results in the most readable / understandable code. Desktop compilers are good and should be able to optimize the result. The impact of one over the other will not be noticed 99% of the time - while the difference will impact code maintenance 100% of the time.

Re:Else ifs - yuck (2)

Dan East (318230) | about a year ago | (#42594041)

Switch statements are faster if there are enough cases, because a branch table can be used. For switches with only a few case statements, a good compiler should use conditional branches, resulting in the same code as an else if, because that is faster in that case. I presume a really good compiler would also be smart enough to use a branch table if enough else ifs are chained together too, but I haven't had to deal with writing that highly optimized code for a while to have been keeping tabs on compilers to that extent.

Re:Else ifs - yuck (2, Informative)

gbjbaanb (229885) | about a year ago | (#42594055)

case statements are not faster than if-else statements. Often a case statement will be turned into a load of if-else's by the compiler anyway (and a set of if-else statements could be turned a lookup table too!)

In any case, "far faster" is not true, the machine statements generated are tiny compared to every other inefficiency in a codebase. Thinking a case statement makes your code faster is like painting your car red to improve its speed when you've got a load of heavy junk in the boot.

Re:Else ifs - yuck (5, Informative)

Anonymous Coward | about a year ago | (#42594303)

Often as in you've measured it, or often as in "I'm making shit up"?

A good compiler will never implement a case statement as a load of if-else's, unless the case values are sparse, or you're not optimizing.

Meanwhile, transforming a set of if-else statements into a lookup table is seldom possible unless the if-elses all compare the same integer variable to a constant. In that case, it can in theory, but almost certainly won't in practice.

Other things being equal, a switch statement with contiguous constant cases will almost always compile to faster code than the equivalent set of if-elses. And it will be far faster. Every if/else induces a branch, and mis-prediction will be severe on most of those branches, causing 10-20+ cycles of stall on modern processors. The jump table mispredicts almost always, but only once. If one arm is taken 99% of the time you can speed things up by using an if/else and then a switch, but that's a rare case.

I appreciate the fact you're responding to the idiocy of the above post, but your points are as wrong as his.

Re:Else ifs - yuck (4, Insightful)

Anonymous Coward | about a year ago | (#42594059)

Are you an idiot? Case statements don't do the same thing as if else. The example in the article does some floating-point compares. How do you represent that as a case statement in C++? Come on, I'm waiting. Oh, that's right. You can't.

Case statements take an integer value and switch based on it. You cannot have case (dot < -epsilon) or case (dot > epsilon). Got that? Good.

wonder what else ID missed

If you think Carmack "missed" something, take a deep breath, count to ten, and figure out what you missed.

No, he's not perfect - I found a bug in DOOM 2 that he never tracked down - but until you prove yourself STFU about how Carmack may have "missed" something you only learned on Stack Overflow anyway. Carmack is a Level 99 Wizard while all you can do is read the descriptions of the kinds of spells he can cast.

God people like you are annoying. Shut up and think, and you might learn something.

Re:Else ifs - yuck (0)

Anonymous Coward | about a year ago | (#42594069)

You don't even know what you don't know

Re:Else ifs - yuck (2)

meerling (1487879) | about a year ago | (#42594261)

Well of course. If you knew what you didn't know, you'd know it instead of not knowing it, you know?

Re:Else ifs - yuck (2)

Deltaspectre (796409) | about a year ago | (#42594091)

Looking at the article, I see nothing that could have been a switch statement. The only else-ifs I see are in the Spacing section, and they need to check if a value is less than or greater than, something that can't be done with a switch.

Re:Else ifs - yuck (0)

Anonymous Coward | about a year ago | (#42594123)

Switch() may be faster (depending on what your compiler does), but is only "far" faster when you have "a lot" case statements that can directly map to the else if conditions.

Refer to this:

Re:Else ifs - yuck (4, Informative)

phantomfive (622387) | about a year ago | (#42594131)

I know some situations else-if statements are necessary, but my understanding is that case statements are far faster.

Very often rules about efficiency like this one are incorrect. Sometimes the compiler will even change things completely when you compile it. In one example, I once carefully wrote a function to only have a return statement at the end, because I (somehow) thought it would be more efficient. Then I looked at the assembly output from the compiler, only to find that the compiler had added in all the extra return statements I had so carefully avoided. After that, I just went with what was most readable.

If you really care about efficiency, there is one way to do it: you MUST time your code. Try the case statement, and time it. Then try the if statements, and time it. If you don't time it, you are just guessing and you WILL be wrong.

The case of the if statements in the article is a tricky example, because it is a range, and writing it as a switch statement would likely be a large table. Doing this could actually slow things down because it fills up the memory caches with mostly needless information. Note this can also be a problem with traditional optimizations like pre-calculated tables or loop unrolling, they can actually slow things down.

TLDR: If you want to make your code efficient, you need to time it.

Re:Else ifs - yuck (1)

hey (83763) | about a year ago | (#42594473)

Probably for a small number of tests else-if is faster (and easier). But when the number of tests is larger I would think switch() would be faster.
(switches us a jump table.) I agree timing is the only way to tell. If you are checking all possible values of a enum using a switch is pretty.

Re:Else ifs - yuck (1)

DdJ (10790) | about a year ago | (#42594537)

Very often rules about efficiency like this one are incorrect.

In particular, they're very often incorrect today, with modern compilers, even if they were true in the very early days.

Many years ago, a co-worker offered to teach us PDP-11 assembly language strictly in order to understand the design of C better. If you've got time, it's a worthwhile exercise. A lot of the design of C makes more sense if you understand how bloody simple a compiler for the PDP-11 could be.

"C combines the power and speed of assembly language with the portability and ease-of-use of assembly language."

Re:Else ifs - yuck (2)

timeOday (582209) | about a year ago | (#42594175)

"Far" faster? Well, maybe percentage-wise. But I bet it would be 0.0001% of program execution for one and 0.00013% for the other. Worrying about the relative speed of alternate constructs and using them everywhere is a backwards approach; instead, find out what's taking most of the time in your code using a profiler, fix it, rinse and repeat.

And since somebody else will say this if I don't, OO enthusiasts have a distaste for both else-if's and case statements, seeing either as a candidate for subclassing and virtual functions.

Re:Else ifs - yuck (0)

Anonymous Coward | about a year ago | (#42594583)

>OO enthusiasts have a distaste for both else-if's and case statements, seeing either as a candidate for subclassing and virtual functions.
I see that as a chance to use MPL and CRTP

The googles, they do nothing! (1)

Anonymous Coward | about a year ago | (#42593903)

The only reason to take *screenshots of code* is if you somehow broke copy/paste.

Mostly right, but a few problems. (4, Interesting)

Anonymous Coward | about a year ago | (#42593965)

I've developed for large game and non-game projects, and each needs a different approach. Console games especially have serious problems with dynamic memory allocation (they don't typically have swap files and can die due to heap fragmentation) so you have to avoid a lot of convenience libraries like STL.

STL, however - especially in newer compilers that support C++0x - is actually quite good and is very, very robust. It's a good way to avoid a lot of the memory management bugaboos that happen when you *are* doing lots of dynamic/heap allocation. So I would very much endorse a sane amount of STL use in desktop code.

The other thing that rubbed me the wrong way here was public member variables. Since inlining and move semantics make getters and setters essentially free, there is no good reason to expose bare, public variables on anything but the simplest, most struct-like objects. The biggest source of weird, hard to trace bugs in our code at the game studio were often due to people modifying public members of other objects in unexpected ways or at unexpected times.

Having public, non-const member variables actually hurts a principle the author supports, which is "Code should be locally coherent and single-functioned". This means that an operation should do one thing and put you in one of several known and easily discoverable states, even on failure. That is, if I say, make this guy do X, then either he does X or he fails and ends up in a known state. If that state is available in the form of modifiable public data, then his state can get messed with at any point along that path by some other code, and the final state (in cases of success and failure) is not fully known. At the very lest, making data private means that only certain code paths can modify the data, and it's much easier to keep state coherent.

Anyway, that's just my $0.02.

Re:Mostly right, but a few problems. (2)

godrik (1287354) | about a year ago | (#42594615)

"The other thing that rubbed me the wrong way here was public member variables."

I am puzzled by that as well. I guess his point is that: foo.setBar(foo.getBar()+3); is much more boring than foo.bar += 3;
I somewhat understand it and I wish we had automatic calls to get and set in C++ like it exists in C# to make core more beautiful.

Yeah... and... (-1)

Anonymous Coward | about a year ago | (#42593989)

No end users give a fuck how 'nice' your code looks if the end result is a pile of shit in shades of brown and black.

So is this why they turned out such garbage? they were only looking at the code and not the end result?

Really this story sounds like some excuse... "well at least the code looks nice!"

This is a must ... (1)

gstoddart (321705) | about a year ago | (#42594031)

According to id's Doom 3 coding standard, they use real tabs that are 4 spaces. Having a consistent tab setting for all programmers allows them horizontally align their class definitions

Years ago I had to have this fight with a co-worker. His electric mode in Emcas was writing out everything as a single tab char, and doing the indenting on its own. The problem is, not everything obeyed this style -- not even a little.

I had to explain to him that since we weren't all using Emcacs, he needed to be sure to leave the code in a usable state because his commits were leaving the whitespace as complete useless crap to everything else.

I don't care what editor you use, but it needs to leave the files in a usable state for everybody else. Having special formatting to work with your editor just pisses everybody else off.

Re:This is a must ... (2)

Hatta (162192) | about a year ago | (#42594409)

I never understood why this was a conflict for programmers. If the white space isn't syntactic, can't your editor just rearrange the code the way you want it? Just run it through a pretty printer before you work on it.

Re:This is a must ... (3, Insightful)

jez9999 (618189) | about a year ago | (#42594425)

Heh... if they're dictating tab width, they're doing it wrong. If you must have a certain tab width, you should be using spaces for everything or you lose the whole benefit of tabs - letting people choose their preferred indentation size.

Use tabs for indentation, spaces for alignment. That way you'll never go wrong. Looks like this was one of the less "beautiful" things about the Doom 3 code.

Comment-free programming (5, Interesting)

swillden (191260) | about a year ago | (#42594101)

I really liked this bit, because it's something I've been really focusing on for the last year or so, and I think it has significantly improved my code:

Comments should be avoided whenever possible. Comments duplicate work when both writing and reading code. If you need to comment something to make it understandable it should probably be rewritten.

Comments can be useful, IMO, but primarily only for generating documentation (think Javadoc or doxygen, etc.). Other exceptions include bits of code that perform highly-optimized mathematical calculations, in which case I think the best solution is to write a proper document and then add a comment linking to the document, and bits of code that do something which apparently could be done differently but for some other reason must not -- assuming that explanation doesn't belong in the doc-generating comments.

Other than that, I find it makes my code a lot better if every time I find myself wanting to write a comment to explain some bit of code's purpose or operation, I instead refactor until the comment is no longer necessary. Often it's as simple as taking a chunk of code from one method/function and pulling it out into another with a well-chosen name, or else introducing a variable to hold an intermediate value in a calculation, with a well-chosen name. Sometimes the fact that a bit of code is hard to explain is a strong indicator that the design is wrong, that stuff is mashed together that shouldn't be.

The bottom line is that I've found eliminating comments does more for improving the readability of my code than anything else, and I've gotten similar feedback from colleagues whose code I critique by pointing out that they can eliminate their comments if they refactor a bit.

Re:Comment-free programming (2)

Anonymous Coward | about a year ago | (#42594687)

I personally like comments and believe that their usage should be reduced when convenient, it should not be avoided whenever possible. In the article he brings up the following snippet as an example:

int idSurface::Split( const idPlane &plane, const float epsilon, idSurface **front,
        idSurface **back, int *frontOnPlaneEdges = NULL, int *backOnPlaneEdges = NULL) const;

And says the following comment is completely unnecessary:
// splits the surface into a front and back surface, the surface itself stays unchange

The amount of time required to write, read and understand the comment is far less than the amount of time needed to read the code, parse each section and understand it, especially after not looking at it for 3 months. Even though the function might seem obvious to a veteran C++ programmer, the comment defiantly nice for those less adept.

Re:Comment-free programming (1)

Anonymous Coward | about a year ago | (#42594889)

I agree that comments do not always help and can obscure the code. But there are many cases when it would be helpful to know why a particular choice was made. Comments help record that history. Also function names, no matter how descriptive, are often ambiguous. Sometimes a comment can help clear up the possible confusion. Coding standards should include what comments to not include. If the comments simply repeat what the source if obviously doing, then those comments clearly can be eliminated. But it's not always obvious why a certain algorithm is used over others, or why a certain magic number is used (some "magic" numbers are necessary so they cannot all be eliminated. It's nice to know how a particular number was chosen).

Work of art. (1)

equex (747231) | about a year ago | (#42594115)

Indeed the code is beautiful and well organized. I think it took me 10 minutes to locate and disable the copy protection, after spending 30 minutes just marveling at the organisation and targeting out code i'd like to steal later. (mostly physics and maths!) Another 5 minutes cleaning up something i don't remember to have it compile. Source download -:> Ready executable ~ 45 minutes. (compiled on an x6).

Re:Work of art. (1)

Anonymous Coward | about a year ago | (#42594533)

An x6? Boy are you in luck. I have an x80 module I'm willing to sell you that will bring you in line with standards!

Most of His Admiration Is Not Technical (5, Insightful)

Greyfox (87712) | about a year ago | (#42594121)

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:Most of His Admiration Is Not Technical (3, Informative)

phantomfive (622387) | about a year ago | (#42594605)

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

Indeed. I would rather have too many comments, to the point that some are not needed, than too few, and remain confused.

Re:Most of His Admiration Is Not Technical (0)

frinsore (153020) | about a year ago | (#42594933)

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

Indeed. I would rather have too many comments, to the point that some are not needed, than too few, and remain confused.

And I would rather have no comments than comments that are incorrect or misleading which cause me to become confused.

C++ for the C++ness of it (2)

caywen (942955) | about a year ago | (#42594157)

I found both the article and what JC wrote to be highly informative and rather validating of my approach to things. In software, we usually get little validation because of the wide variety of opinions of who we work with. We've all seen the extremes: The hard core C programmer who can't be bothered with any OO nonsense, and who advocates inspecting the assembly of every method you write. The C++ hippie who sees everything as some kind of exercise in getting the compiler to write the code for you.

I'm sure most of us follow a more balanced approach. C++ has to be about performance over anything else, otherwise there are plenty of other languages that accomplish much greater degrees of expression, but can't cash the performance check. But, expressibility is important, too, because performance goes out the door once we stop understanding what the code is doing. It's nice to have a language that lets you express things somewhat functionally, yet gives you the flexibility to wring out serious performance.

Const for pass by value is poinltess (0)

Anonymous Coward | about a year ago | (#42594171)

It is pointless to make f(const float parm) const because it cannot change whether it is const or not. C++ passes by value. If you really want to be purposeful say f(const float& parm). This is a basic review item. Read Lakos. The author doesn't know what he is doing.

I summon thee! (-1)

Anonymous Coward | about a year ago | (#42594215)

In the name of all that is unholy, I summon the King Troll by uttering his vile name three times:

APK! APK! APK!!!!!!

Beauty is in the eye of the editor (0)

Anonymous Coward | about a year ago | (#42594253)

I read this article yesterday when it was on Kotaku. I have some issues with some of the statements, several of which (such as comments and {} formatting) really depend on the editor being used.

I think the author believes that the Doom 3 code is beautiful because it matches his own coding style preference. Truly beautiful code is beautiful not because of style, but because the code is extensible, robust, and maintainable. Many of the arguments in the article touch on several of those points, but don't really tie in strong enough to definitively prove the code to be beautiful. For me, the most important of those three is the last mentioned, maintainable. A programmer is happy when the code they must maintain (perhaps written originally by another person or team) is easy and straight forward to maintain. Robustness and extensibility tie into maintainability. I say code is beautiful when I can spend minimal time fixing errors and maximizing the number of new features in that code.

lost me (3, Interesting)

j00r0m4nc3r (959816) | about a year ago | (#42594299)

after the first three conclusions, and i stopped reading so i can't speak for the rest. should be: 1.) const as appropriate, not "const everything possible". const can fuck you hard in OOP if you use it wrong, 2.) you can never have too many comments, and 3.) tight vertical spacing is archaic and stupid, unless absolutely necessary for some display reason

if this guy was interviewing here and mentioned all the things in his article, i probably wouldn't hire him. too much "religion", as it were, which is a huge red flag for me because it's usually masking something...

Re:lost me (1)

Anonymous Coward | about a year ago | (#42594621)

I mostly agree, but yes, you CAN have to many comments. I once was on a project were the existing code had literally paragraphs of comments per line of code. I am not exaggerate. It was extremely hard to read that code.

you're obviously not a game developer (1)

Anonymous Coward | about a year ago | (#42594863)

As an engine programmer at one of his competitors, I can assert that I completely agree with all of his opinions, especially "if it needs comments, it should probably be re-written" and "const everything as possible". Also we use our own STL-like containers, we don't use an off-the-shelf STL implementation because most of them are more bloated than we would like on consoles (e.g. too much inlined code)

Its been my experience that (0)

TheSkepticalOptimist (898384) | about a year ago | (#42594509)

The people that worry about coding style don't write good code. It might look nice, but is fundamentally they don't spend enough time on functionality.

I have found consistently that the big office blowhard developer that sends out numerous emails and writes documents about the company's coding style practices is typically the person who is the worst programmer in the bunch. He only writes beautifully coded bugs.

Re:Its been my experience that (0)

Anonymous Coward | about a year ago | (#42594789)

Is that you, Eric? How many times do I have to tell you, don't write all your code on a single line with 100 ;'s in it and don't call all your variables ericsBaby1, ericsBaby2, ... On a serious note, if you are not thinking about your coding style and practices as a way to reduce the bug count, you're missing a tool in your belt that could make you a more skillful developer.

subjective (1)

TsuruchiBrian (2731979) | about a year ago | (#42594595)

This is a perfect example of why code beauty is subjective. On the one hand the author loves saving vertical space by not putting parentheses on their own lines, then he hates it when you remove them entirely, even though it saves even more space. He finds conditionals without parentheses to be less readable. I find non-horizontally aligned parentheses less readable, and have no problem following conditionals without them.

I think where it becomes less arbitrary (but still subjective) is in the actual design. I don't see the point of not using STL. Being able to write 1 hash (or use someone else's) without needing multiple copies in the code simply to deal with different types seems great to me. Yeah it's a little harder to read, but you only need to read one of them, and you know all the hashes are the same unless there are methods overloaded for different types. Checking that each part of 2 classes that look identical except for types, are actually identical is tedious.

Sometimes there is a tradeoff between code readability and design. I tend to favor design over readability. Inheritance makes code less readable, but if done correctly, it makes the design much better by reducing redundant code. Redundant code may be perfectly readable, but it makes it much harder to "read" the design of the application.

Re:subjective (3, Informative)

UnknownSoldier (67820) | about a year ago | (#42594895)

> I don't see the point of not using STL.

Code bloat, hard to debug, memory fragmentation, and no way to serialize/deserialize in a fast way.

I highly recommend ALL C++ programmers to read this doc on why EA designed and implemented their own STL version. It provides insight into the type of problems console game developers have face that the PC game developers just routinely ignore or are ignorant of.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html [open-std.org]

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account