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

We're all consenting adults. Python gets by just fine on this principle.

Since we're playing Space Nazi, I like this better:

  for (int 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]]++;
    }

Note that emacs will tab-align the table rows properly if you break the sides[i] = line after the = which is why I did it; not sure about vim.

If multiple people rearrange the white space at the same time as adding variables (e.g., because the new variables are of types whose names are different widths, both wider than the old gap), you are more likely to get a conflict than if they just leave the spacing alone. Many version control systems seem to tend to do their automated merges line by line, and this sort of edit seems to give them less to work with. [8c99a51796e06219f472f78a5c081dd664da83dc]

Then the wrath comes when you get latest (pull, update, fetch, rebase, call it what you will) and have an inconvenient merge forced on you! I've always personally found the fact that it's just adding or removing white space especially galling :) - but tastes may differ.

It strikes me that your argument taken to the extreme is that everybody should program in assembly language because you can do anything, anytime, anywhere. Well, at least as far as control flow structures are concerned. Certainly C is preferable to C++ if you want simple and malleable code.

Do you also prefer if-else to switch statements? (I'm not sure.)

Do you like to use goto? (I doubt it.)

Do you eschew the use of classes and inheritance? (I doubt it.)

Do you keep all your code in one file? (I'd be very surprised.)

My point with these semi-facetious questions is that structure is important and regularity in a codebase does wonders for comprehensibility and maintainability. I agree with you for the case in which you do actually have something where the underlying structure is likely to change, in that then it does make sense to write it with malleability in mind.

Consider something like command line options processing. You have 50 options. You might want a 51st option. It makes sense to use the most regular structures you can so that people don't start special-casing stuff in the middle of it all. That, or to use an options library that defines the allowable formats for you.

Part of me thinks you're just having an allergic reaction to ?: simply because it is pretty unusual the first time you see it used seriously. But it can simplify so much:

Compare:

  if (a)
    {
      return b;
    }
  return c;

to:

  return a ? b : c;

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 other people finally told him to stop).

2. It messes up diffs. Now instead of one line showing up in the diff, the entire block is often different. And yes, most diff tools have options to hide whitespace differences. Again, though, this adds overhead to everyone who doesn't want this block style. I'd rather not hide whitespace differences, because if someone has added a bunch of inappropriate whitespace (or mangled the block while trying to reformat it to include their new variable), I want to know about it during the code review so I can tell them to fix it then rather than finding it later when I'm editing the file.

3. It doesn't actually help anything. Yes, you get a nice column that shows you all the variable names. What good is that, though? Unless you're putting everything at the top of the function (which has its own set of problems), you're not really getting anything useful from this except maybe prettier code (arguable), because at a glance you still don't really get know all the in-scope variables (not to mention file-scope variables). Moreover, you actually lose something valuable with this style, because now it's harder to determine a variable's type. You're trying to scan left from the name across some indeterminate amount of whitespace to match with the type. This is not typically easy to do, which is why column-oriented data is typically displayed with alternating background colors on each row.