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

Post by dchichkov » Mon, Jan 14, 2013, 8:40 PM UTC

  for ( i = 0; i numVerts ; i++ ) {
      dot = plane.Distance( in->verts[i] );
      dists[i] = dot;
      if ( dot  LIGHT_CLIP_EPSILON ) {
          sides[i] = SIDE_FRONT;
      } else {
          sides[i]  = SIDE_ON;
      }
      counts[sides[i]]++;
  }

  for(i = 0; i numVerts; i++)
  {
      dot = plane.Distance(in->verts[i]);
      
      dists[i] = dot;
      sides[i] = dot  LIGHT_CLIP_EPSILON   ?  SIDE_FRONT :
                                               SIDE_ON;

      counts[sides[i]]++;
  }

Post by nirvdrum » Mon, Jan 14, 2013, 8:42 PM UTC

scanr wrote: post #35

nirvdrum wrote: post #18

Earlier quoted context omitted.

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…

> Clarity can usually be addressed with longer variable or method names, but there's a strong culture against that in nearly ever programming community. It would be interesting to see a list of those that discourage long method and variable names. I haven't seen anything that suggests that Java, Ruby, Python, Haskell, Kotlin, Scala, PHP, Groovy etc. discourage long variable and method names.

Post by zem » Mon, Jan 14, 2013, 8:42 PM UTC

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…

Post by kstenerud » Mon, Jan 14, 2013, 8:43 PM UTC

alanctgardner2 wrote: post #19

nitrogen wrote: post #14

Earlier quoted context omitted.

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

Post by Camillo » Mon, Jan 14, 2013, 8:47 PM UTC

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.