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

11–20 of 210 posts

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

#11

Post by HeXetic »

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 minimal to non-existent. Global variables are everywhere.

It made some of the functions I had to modify so hard to read that I wound up completely editing them, particularly those variable-declaration blocks, even though I ultimately only needed to change a line or two to get my mod to work.

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

#12

Post by ExpiredLink »

> C++ code can quickly get unruly and ugly without diligence on the part of the programmers. To see how bad things can get, check out the STL source code. Microsoft's and GCC's[5] STL implementations are probably the ugliest source code I've ever seen. Even when programmers take extreme care to make their template code as readable as possible it's still a complete mess. Take a look at Andrei Alexandrescu's Loki library, or the boost libraries—these are written by some of the best C++ programmers in the world and great care was taken to make them as beautiful as possible, and they're still ugly and basically unreadable."

Finally, a guru dares to call a spade a spade. Header-only, template-only C++ programming is a mistake! After 1995 C++ Standardization took the wrong path and lost contact with real world developers. The glorification and idolization of 'STL programming' was in sharp contrast with programmer's needs. Today in C++ there is a chasm like in no other language between the 'official language' and what programmers need and use day in day out.

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

#13

Post by agumonkey »

jlongster wrote: post #2

My heart grew a little warm with the last paragraph of John Carmack's comment: "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."

Tim Sweeney of Epic also praised functional programming few years ago http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-...

I don't know what's his stance on the subject since though.

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

#14

Post by nitrogen »

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.

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

#15

Post by MichaelSalib »

ExpiredLink wrote: post #12

> C++ code can quickly get unruly and ugly without diligence on the part of the programmers. To see how bad things can get, check out the STL source code. Microsoft's and GCC's[5] STL implementations are probably the ugliest source code I've ever seen. Even when programmers take extreme care to make their template code as readable as possible it's still a complete mess. Take a look at Andrei Alexandrescu's Loki libra…

What's odd is that the C++ community fetishizes these techniques so much. I mean, when faced with problems that require running code at compile team, the lisp community's answer was "ok, just include an interpreter and run your lisp code at compile time with eval-when". The C++ community first insisted that there was never a reason for doing so and then said "ok, but instead of writing code for compile-time execution using C++, we're going to create an nightmarishly complex and crippled language that you'll use instead; it will be so painful that you'll be proud of implementing factorial".

And now a whole new generation of programmers can gaze at the horror of Modern C++ metaprogramming and conclude that metaprogramming is bad....

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

#16

Post by dasil003 »

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…

Carmack's comment acknowledges as much without being ungracious to the author.

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

#17

Post by greggman »

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 benefits did the change provide? What problems did the change introduce?

Abstract talk is interesting but "show me the Money!" ;-)

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

#18

Post by nirvdrum »

RyanZAG wrote: post #10
nirvdrum wrote: post #6

The 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…

Oh, I get the concept. I've just been doing this for a while and see it fall part constantly. The problem is always that what is clear to you isn't clear to everyone else, including yourself somewhere down the road. And decomposing everything to atoms tends to lead to a mess of indirection.

Clarity can usually be addressed with longer variable or method names, but there's a strong culture against that in nearly ever programming community.

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

#19

Post by alanctgardner2 »

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.

I was reading '21st Century C' (I strongly recommend it for anyone writing C on a regular basis), and the author also argued against declaring all the variables up front. I don't quite know why, but I had a very strong reaction against it. As far as best practices go, I would try to keep every function small enough that you can find all the stack variables easily. If the function gets too hairy, refactor it so you can follow where the variables are going.

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

#20

Post by Cowen »

jlongster wrote: post #2

My heart grew a little warm with the last paragraph of John Carmack's comment: "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."

He's mentioned before that he's toyed with the idea of switching to Haskell.

That wasn't for functional programming though. It was instead for the built-in static code analysis the Haskell type system and compiler provides.

Post reply on HN