Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

John Carmack's comment on Doom 3's code style

kotaku.com

Post reply on HN
Print view View original

61–70 of 210 posts

Re: John Carmack's comment on Doom 3's code style

#61

Post by HeXetic »

alecdbrooks wrote: post #44
HeXetic wrote: post #11

As someone who has worked with the Doom 3 source code for a mod, I have the opposite opinion. The code very clearly shows a programming team (or programmer) in the process of transitioning from old-school C to C++. Most functions have a huge blob of variable declarations right at the top, as was once necessary in C, even though these variables aren't used until later, or possibly even at all. Usage of const is minima…

You might be correct, but I cannot say, having never read the source code. Since it was Carmack's first project in C++, I am inclined to believe you. But would you agree that the practices mentioned in the article are what the team got right? You can remove the author's gushing about the code's beauty and have a substantive article left. For instance, the section on vertical spacing had me reconsidering my own style.…

Personally, I found some of the horizontal spacing excessive. There were several lines that even forced me to scroll horizontally within VisualStudio (with a few side-panes open, admittedly), despite having a widescreen monitor. I'm pretty sure I chunked those up. Maybe Mr. Carmack has a much bigger monitor than I did.

Besides that, I think the stylistic changes this author is commenting on are fairly minor. I think the conciseness of vertical space was a bit confusing sometimes; this article only shows the simple functions where it works. The almost complete absence of templated is more likely because no STL code was used.

Certainly, the code base is very thorough. When I realized I had to use quaternions to represent the player's orientation in the game space, there was already an idQuat class ready and waiting and fully functional, which was very nice. I think that idQuat class was never even used anywhere in the base code, so it was cool -- for someone with who never knew about quaternions before then -- to have a class fully implemented and ready for me to use.

Re: John Carmack's comment on Doom 3's code style

#62

Post by HeXetic »

nitrogen wrote: post #14
HeXetic wrote: post #11

As someone who has worked with the Doom 3 source code for a mod, I have the opposite opinion. The code very clearly shows a programming team (or programmer) in the process of transitioning from old-school C to C++. Most functions have a huge blob of variable declarations right at the top, as was once necessary in C, even though these variables aren't used until later, or possibly even at all. Usage of const is minima…

What do you find so disagreeable about collecting variables at the top of a function? For the most part, I like having all the variable declarations at the top, so it's easy to see what names are in what scope.

Among other things already mentioned, it makes it impossible to be "const pedantic" as Mr. Carmack professes to now be, i.e. declaring everything that is only initialized and then never changed as const.

I most certainly am const pedantic as well, and I was back when I worked on this project, too -- quite a few of the "inconsequential" lines I checked in were simply moving a variable declaration down to where it was initialized, and adding 'const'. I found the resulting code much easier to read.

Re: John Carmack's comment on Doom 3's code style

#63

Post by Garoof »

jblow wrote: post #51
Cushman wrote: post #50

Earlier quoted context omitted.

Bravo. That comparison makes worrying about vertical space seem ludicrous.

Ugh. I prefer the Carmack version. This example turns the code into something that appears more airy but in fact is much harder to understand due to extensive use of ? :. I find that one of my own major steps toward programming maturity happened when I stopped doing goofy things like this and started writing code that was as simple as possible to logically follow, and that was as un-special-cased as possible. (By thi…

I like the last one better. I think it reads more like "assign one of these values to sides[i]" and less like "do one of these three things".

"By this latter I mean, if you change the code a little bit, you don't have to rewrite it; it looks basically the same."

I'd say that's kind of the point though. The first one would look "basically the same" if in the last else it assigned to sides[j] instead of sides[i]. In the last one it would look very different if it was about "doing stuff" rather than choosing which value should go to sides[i].

Re: John Carmack's comment on Doom 3's code style

#64

Post by Jabbles »

zxcdw wrote: post #48
Jabbles wrote: post #22

I don't have much experience with C++ codebases, but is this really "exceptional beauty"? The majority of the things he comments on could be enforced with a code-formatter.

Considering the codebase is around a decade old, how many code formatters existed for C/C++ back then? I am asking because I've only used gofmt to format Go code and infact it was gofmt which introduced the whole concept to me.

Astyle seems to have been around that long, I imagine pure C formatters have existed for much longer. They've got a lot in common with a language parser so if you've got a compiler you're most of the way there.

http://astyle.sourceforge.net/notes.html

I think Go is pretty unusual in that gofmt is provided with the language. So all Go everywhere looks the same. It's awesome isn't it? :)

Re: John Carmack's comment on Doom 3's code style

#65

Post by quux »

mark-r wrote: post #23
quux wrote: post #7

Earlier quoted context omitted.

John Carmack wrote a nice article about experiences writing functional code in C++ here: http://www.altdevblogaday.com/2012/04/26/functional-programm...

That very link was at the bottom of his original response.

Ah, didn't notice it. Thanks.

If I missed it, I can't be the only one.

Re: John Carmack's comment on Doom 3's code style

#66

Post by kybernetyk »

zxcdw wrote: post #48
Jabbles wrote: post #22

I don't have much experience with C++ codebases, but is this really "exceptional beauty"? The majority of the things he comments on could be enforced with a code-formatter.

Considering the codebase is around a decade old, how many code formatters existed for C/C++ back then? I am asking because I've only used gofmt to format Go code and infact it was gofmt which introduced the whole concept to me.

I can remember using AStyle in ~2003. I think it's a little older than that.

Re: John Carmack's comment on Doom 3's code style

#67

Post by Cushman »

jblow wrote: post #51
Cushman wrote: post #50

Earlier quoted context omitted.

Bravo. That comparison makes worrying about vertical space seem ludicrous.

Ugh. I prefer the Carmack version. This example turns the code into something that appears more airy but in fact is much harder to understand due to extensive use of ? :. I find that one of my own major steps toward programming maturity happened when I stopped doing goofy things like this and started writing code that was as simple as possible to logically follow, and that was as un-special-cased as possible. (By thi…

...really? I don't even write C that often, and I didn't find that difficult at all. Even if you don't grok the syntax yet, it just does what it seems like it does at first glance. And how on earth does a two-long ternary chain strike you as "extensive"?

If you want to do something in addition to assignment, it's really quite easy: Just add a new `if` block underneath. This clearly separates your conditional assignment from whatever else is going on that may or may not be related to the assignment. (What if you add something besides assignment to the if, but then want to change the conditions for only that? You have to rewrite the whole thing!)

Re: John Carmack's comment on Doom 3's code style

#68

Post by rachelbythebay »

nostrademons wrote: post #28

A lot of the practices here are enshrined in the Google C++ styleguide: http://google-styleguide.googlecode.com/svn/trunk/cppguide.x... The author's first point about establishing conventions so that you can re-use the code that works with those conventions is very important. At Google, nobody writes code to serialize/deserialize bytes, because the default answer is just "use protobufs". Nobody writes low-level commu…

Autotest: pickles over ssh stdin/stdout. They would have also had base64-encoded pickles in mdb labels if I hadn't stopped them. Or who knows, maybe they went through with it with me out of the way.

Logjammer/Treehorn: XMLRPC. (Yes, what a horrible project name. Juveniles.)

There are others. NIH actually happens inside the company too.

Re: John Carmack's comment on Doom 3's code style

#69

Post by linhat »

zem wrote: post #45
nostrademons wrote: post #28

A lot of the practices here are enshrined in the Google C++ styleguide: http://google-styleguide.googlecode.com/svn/trunk/cppguide.x... The author's first point about establishing conventions so that you can re-use the code that works with those conventions is very important. At Google, nobody writes code to serialize/deserialize bytes, because the default answer is just "use protobufs". Nobody writes low-level commu…

> A lot of the practices here are enshrined in the Google C++ styleguide: with the notable exception of lining up things horizontally, which tends to be frowned on.

I really do not understand why they chose to do so. In my opinion, it does not improve readability at all, even worse, when the spacing between type and name gets big, your eyes need more work to figure out the correct line relations.

Furthermore, this can generate horrible commits, for example:

  int x;
  int y;
becomes:

  int   x;
  int   y;
  float z;
after adding ONE single variable. But your commit will contain changes for the above 2 lines. This will make for an insane experience once your variable list grows to a certain size (including multiple spacing changes) and you intend to rollback/cherry-pick/time-warp. Then you will get to deal with the full wrath of conflict resolution. Also, your commit (of one logical line change) contains way to much meta info, which also decreases commit/diff readability.

Re: John Carmack's comment on Doom 3's code style

#70

Post by dchichkov »

Garoof wrote: post #63
jblow wrote: post #51

Earlier quoted context omitted.

Ugh. I prefer the Carmack version. This example turns the code into something that appears more airy but in fact is much harder to understand due to extensive use of ? :. I find that one of my own major steps toward programming maturity happened when I stopped doing goofy things like this and started writing code that was as simple as possible to logically follow, and that was as un-special-cased as possible. (By thi…

I like the last one better. I think it reads more like "assign one of these values to sides[i]" and less like "do one of these three things". "By this latter I mean, if you change the code a little bit, you don't have to rewrite it; it looks basically the same." I'd say that's kind of the point though. The first one would look "basically the same" if in the last else it assigned to sides[j] instead of sides[i]. In th…

Precisely. And there is even a little bit more to it.

1. it reads "assign one of these values to sides[i]". 2. it would not allow some other peoples spurious code into the assignment. which is a good thing. 3. space is used to convey meaning; note how sides[i] stands next to dists[i]; ternary operation is formatted as a table, etc.

Post reply on HN