I don't like this coding style at all. There are quite a few inconsistency with respect to the formatting, for example:
common->Frame(){ session->Frame() { ... } }
etc.
John Carmack's comment on Doom 3's code style
151–160 of 210 posts
Re: John Carmack's comment on Doom 3's code style
#152As 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…
I don't really know who the writer is, but Carmack's comment seems to indicate that it was very much a first pass at writing C++.
There's two things here that irk me a little bit:
the stream operator overloading - maybe I have been writing C++ for many years, but I can't get behind using printf vs. stringstream because public variables because you don't like adding accessor/mutator methods.
Other than those two everything else is a stylistic preference that I mostly agree with. Statement braces around control blocks should absolutely be a requirement as well as pedantic const.
Re: John Carmack's comment on Doom 3's code style
#153I've loved John's code since I saw it first time when the original Quake was leaked from their FTP site through IP spoofing. I was just a kid at that time, and it was an amazing experience to hack it. Yet now, the first example that I saw in this article hurts my eyes. Compare: for ( i = 0; i numVerts ; i++ ) { dot = plane.Distance( in->verts[i] ); dists[i] = dot; if ( dot LIGHT_CLIP_EPSILON ) { sides[i] = SIDE_FRONT…
Well, let me state this: John's version is not to my preference 'cause it has { in the same line as if, but I can live with that. But YOUR version uses not only the ? operator, which should be burned with fire but it NESTS two of them together. Please, I want to die now. :( Conclusion: We have different preferences.
the ternary operator is awesome. it should be used more often.
Re: John Carmack's comment on Doom 3's code style
#154I've loved John's code since I saw it first time when the original Quake was leaked from their FTP site through IP spoofing. I was just a kid at that time, and it was an amazing experience to hack it. Yet now, the first example that I saw in this article hurts my eyes. Compare: for ( i = 0; i numVerts ; i++ ) { dot = plane.Distance( in->verts[i] ); dists[i] = dot; if ( dot LIGHT_CLIP_EPSILON ) { sides[i] = SIDE_FRONT…
Well, let me state this: John's version is not to my preference 'cause it has { in the same line as if, but I can live with that. But YOUR version uses not only the ? operator, which should be burned with fire but it NESTS two of them together. Please, I want to die now. :( Conclusion: We have different preferences.
The chained ?: idiom is very common in some C codebases. Having experienced it there, I find it highly readable, but it can sometimes benefit from parentheses to clarify precedence.
Re: John Carmack's comment on Doom 3's code style
#155Comments should be about why a piece of code does what it does not about what (should be clear from the function/method name) or how (should be clear from the code itself). As long as the comment just explains why it should be as long and detailed as necessary.
That is so wrong. Mathematical thesis are using a syntax arguably much much more powerful than programming languages and yet they're still using lots and lots of english to describe what the formulas are doing and why they're (supposedly) correct in doing so. I very much prefer to have 1000 lines of some Lisp dialect with lots of comments about what the code does than 10 000 lines of "self-explaining" Java/C# code. C…
>Comments cannot.
I disagree. While the comments won't break your code, they can certainly ease the introduction of bugs, and cause cognitive delays when they're wrong or out of date.
Comments need as much care as the code itself, with the DRY principle guiding when they need to be pruned.
Re: John Carmack's comment on Doom 3's code style
#156Earlier quoted context omitted.
Well, let me state this: John's version is not to my preference 'cause it has { in the same line as if, but I can live with that. But YOUR version uses not only the ? operator, which should be burned with fire but it NESTS two of them together. Please, I want to die now. :( Conclusion: We have different preferences.
the ternary operator is awesome. it should be used more often.
Yeah, I really like it.
It's a nice little oasis of Functional style in an otherwise pretty un-Functional language.
Re: John Carmack's comment on Doom 3's code style
#157Earlier quoted context omitted.
It depends. But in this particular case, some trivial extra code inserted inside that if statement may break things. Like breaking vectorization of that 'for' (note, that we are going over vertices). When you are writing the code, some times you may want to put additional constraints on the allowed operations, modifications, etc. A trivial example in C++ would be using 'const &' instead of '&'.
This is true (especially: breaking vectorization). But premature optimization is not a good idea, and if you are doing real optimization, you are going to rewrite that piece of code 10 times anyway, so it is in a different class of problem and the putty stuff I was saying before does not apply (i.e. this code is in the 1% or so of the codebase that is highly performance-sensitive). Optimized code is just a different…
Who's to say that code isn't the tenth iteration? Especially given the context of the discussion...
Re: John Carmack's comment on Doom 3's code style
#158As 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.
Besides the other points made it can prevent usage of const.
Re: John Carmack's comment on Doom 3's code style
#159The author seems to like the minimalistic comments. I wonder if the team looked back what their thoughts would be. I can barely look at code I wrote a year ago and not ask what the hell I was thinking, but in my mind it was absolutely clear at the time. I guess an impartial third party reading it and understanding it is a strong testimonial.
The key is to have self documenting code, not undocumented code. If you create functions that do only a single thing, with their purpose fully described by their method signature then you don't need comments - the method itself explains exactly what it does. The author makes a good point that comments are just more text that you need to maintain, and whenever you make changes you now have to make changes in two place…
For me, external documentation is the absolute worst scenario. It takes me at least 4 times longer to read through and understand code without comments explaining in English what's going on. Here's a real-life example:
// Toggle between Dropdown and Text
if(_protected.fields[field].fieldType() === "Dropdown") {
_protected.fields[field].set("fieldType", "Text");
} else {
_protected.fields[field].set("fieldType", "Dropdown");
}
Re: John Carmack's comment on Doom 3's code style
#160Earlier quoted context omitted.
Maybe I miscommunicated; I'm not against declaring variables at scopes smaller than the function - I declare variables at the top of conditional branches as well. I still don't buy the 'twice as many lines' reason for mixing assignment and declaration.
You should be using const variables as much as possible (and in general preferring immutable data). In that case assignment and declaration _must_ take place at the same location.
this