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

131–140 of 210 posts

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

#131

Post by daemin »

npsimons wrote: post #98
dysoco wrote: post #75

So he discourages Getters/Setters and instead says that declaring the variable as Public is better? I mean, isn't that like not giving a sh-- about encapsulation principles ?

I'm kind of the same opinion as Carmack re: getters/setters. My feeling is, if all you're going to do is allow clients to read and write the variable, why not just expose it? Sure, you can argue encapsulation and even justify it by saying that later down the road you may want to change the implementation, but far too often I've seen C++ classes with a setter and getter for every variable, for no good reason (eg, they…

Some arguments in favour of getters and setters are; that using a function allows for the addition of caching, addition of thread safety checks, changing to compute the variable rather than store it, addition of logging, mapping it to be generated from another variable, etc.

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

#132

Post by aardvark179 »

ajross wrote: post #29
melling wrote: post #4

"I am a full const nazi nowadays, and I chide any programmer that doesn’t const every variable and parameter that can be." Immutability...one less thing to worry about.

Yes, but it's easy to spend way too much time chasing that stuff, too. The API you're working with may not itself be const-clean, so you end up with a zillion const_cast expressions translating your "cleanly consted" local expressions into something the compiler will accept. And all that junk hurts maintainability and readability; you end up being tempted into nonsense like "caching" your non-const handle just to avo…

I think that highlights a broader point that is touched on by the article. The Doom 3 code is not idiomatic C++ the way many would think of it but it does build its own consistent idioms and sticks with them wherever reasonable. It can do this through having a fairly small number of points where it touches the external world and ensuring that its idioms are compatible with that world.

If you're building a program in any language and it interacts heavily with a particular library then you'd better write something idiomatic to that library. If you're going to be using several libraries (including your language's standard lib) with different idioms then one of the most important design decisions you can make is how to bridge them, and where to make compromises.

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

#133

Post by groby_b »

greggman wrote: post #17

It would be really helpful to have some real world examples of changes going from C++ OOP to C++ functional and include the trade-offs. By concrete I mean what changed in Id's code (or some other game or ui framework), and not just some text book example. What changed in GameObject or PhysicsSphereObject or RenderableSkinnedMesh or whatever things changed. What did the code used be like? What was changed? What benefi…

Go search for "data oriented programming". Mike Acton wrote a few interesting presos on it, GameDevADay blog has a few others, too.

Yes, technically they have different motivations for going the way they go, but the end results tend to coincide neatly :)

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

#134

Post by chj »

dchichkov wrote: post #41

I'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…

Honestly your version is worse. ?: is cryptic, you should not use it except in extremely simple cases.

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

#135

Post by groby_b »

daemin wrote: post #131
npsimons wrote: post #98

Earlier quoted context omitted.

I'm kind of the same opinion as Carmack re: getters/setters. My feeling is, if all you're going to do is allow clients to read and write the variable, why not just expose it? Sure, you can argue encapsulation and even justify it by saying that later down the road you may want to change the implementation, but far too often I've seen C++ classes with a setter and getter for every variable, for no good reason (eg, they…

Some arguments in favour of getters and setters are; that using a function allows for the addition of caching, addition of thread safety checks, changing to compute the variable rather than store it, addition of logging, mapping it to be generated from another variable, etc.

All of these are usually made by theoretical purists. Meanwhile, the people who write the code see that most variables don't need any of the above, most of the time.

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

#136

Post by dchichkov »

jblow wrote: post #128
dchichkov wrote: post #120

Earlier quoted context omitted.

And again it depends. I would return to a simple example of passing a parameter by a const reference. When you are writing this const in the "const std::string &name" you are 1) constraining developers from breaking things 2) making the code more efficient 3) providing clues to other developers 4) providing clues to optimizer. All of these points are important to some degree. And it is just the same, when you are wri…

I think we have different ideas about what constitutes optimization. Sure, putting const in parameter declarations is easy to do. It may even buy you a little bit of speed because the compiler is a little bit clearer about pointer aliasing and whatever. But it's not going to make a difference in the equivalence classes of slow code / fast code / Really Fast Code. Serious hardcore optimization usually involves changin…

Thanks. I've really enjoyed that discussion with you. And by the way, your comment mentioning several decades of experience was certainly appropriate.

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

#137

Post by georgeorwell »

jblow wrote: post #114
georgeorwell wrote: post #107

Earlier quoted context omitted.

I'm not even clear that it's clear I didn't understand your point. I guess I have trouble communicating effectively. I thought your point was that flexible control flow structures like if-else allow you to change code quickly and more easily in the future. Wasn't that the point? Assuming I have understood your preference for flexible code, I am simply stating my belief that it is useful to balance this with rigid cod…

Sometimes rigid code is simpler, sure. But what I am arguing is that it is almost never more debuggable / maintainable. What I am saying is not specific to test and branch, though test and branch is great because it gives you these big code blocks into which you can insert more code and it's clear where that code lives and under what circumstances it runs. Which is something you don't get in assembly language, which…

I used the word extreme in the assembly language argument to indicate that I understood you weren't actually advocating people program in assembly. So I don't consider it a straw man. Rather, it was an example of extremely flexible control flow. Sometimes this is what you need. Sometimes you need to modify the stack so that a function is called in a different way. Sometimes gotos can provide significantly more efficient code. Sometimes vtables are too expensive. Rails is at the opposite end of the spectrum, it is very rigid. As a refutation to your argument against rigid code, a lot of people consider Rails code to be debuggable and maintainable. Personally, I like a middle ground and try to be aware of the costs and benefits of making and using cookie cutters, an example of which is chained ?:.

I was not asking questions to "destroy your argument", I was trying to establish different contributors to rigidity / flexibility. It seemed to me that in your argument you were dismissing rigidity - certainly you weren't praising it - and I wanted to point out that in the use of any control flow more complicated than test and branch you are in fact relying on rigidity. If this is a "straw man" in your eyes, then so be it. Having functions introduces rigidity! Even if-else enforces some things. If anything, I was just actually interested in the topic, because I hadn't really thought much about the tradeoffs of rigid vs. flexible in those specific terms and I wanted to explore them a bit.

What if I revealed myself to you, and then you were like, oh shit, I better take what he says a little bit more seriously, wouldn't that just be embarrassing? I don't want to do that to you.

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

#138

Post by nitrogen »

dpark wrote: post #89
swift wrote: post #57

Earlier quoted context omitted.

Regarding poor_style(), I've never understood this objection (and indeed I prefer the block style you complain about there). Can't your editor fix this up for you in a few keystrokes? This is the sort of thing that an editor should make easy.

I have a few objections: 1. It wastes my time. Sure, I could probably set up my editor to fix this, but I shouldn't have to do so to satisfy someone else's pointless indentation fetish. I've personally never worked on a team where this was an accepted, general guideline. It was always just one guy who wanted this, and did it to every function he touched, adding maintenance headaches for everyone else (until/unless ot…

I bet that some programmers' brains need those orderly columns in order to be able to parse the code effectively, overwhelmed by the chaos of rivers of whitespace otherwise. In that case, it sounds like an editor that displays in columns but stores in compact form would be helpful.

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

#139

Post by jblow »

georgeorwell wrote: post #137
jblow wrote: post #114

Earlier quoted context omitted.

Sometimes rigid code is simpler, sure. But what I am arguing is that it is almost never more debuggable / maintainable. What I am saying is not specific to test and branch, though test and branch is great because it gives you these big code blocks into which you can insert more code and it's clear where that code lives and under what circumstances it runs. Which is something you don't get in assembly language, which…

I used the word extreme in the assembly language argument to indicate that I understood you weren't actually advocating people program in assembly. So I don't consider it a straw man. Rather, it was an example of extremely flexible control flow. Sometimes this is what you need. Sometimes you need to modify the stack so that a function is called in a different way. Sometimes gotos can provide significantly more effici…

Creepy reply is creepy.

About this:

"Plus, I mean, what if I revealed myself to you, and then you were like, oh shit, I better take what he says a little bit more seriously, wouldn't that just be embarrassing? I don't want to do that to you."

No, by all means, go ahead. I am interested in having a productive discussion about programming, so if you can share your experience in a way that convinces me, I am totally open to it. If it turns out I am wrong, I won't be embarrassed, I will just change my opinion so that I am not wrong any more. This is how one becomes a good programmer in the first place: by paying attention to what is empirically true, rather than what one is originally taught or what seems exciting or what is in theory better.

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

#140

Post by martinced »

edu wrote: post #9

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

Code can contain bugs. Comments cannot.

Post reply on HN