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

Furthermore, this can generate horrible commits, for example:

  int x;
  int y;

  int   x;
  int   y;
  float z;

If you'd asked the standards body to add a turing complete type-level meta-programming language to C++ in order to generate code at compile time I suspect they'd have told you to get knotted.

What people actually asked for was a reasonable syntax for adding generic functions to C++ that would not carry any runtime cost. Sounds completely reasonable, right? The standards group said "sure, how about this?", and kept adding more perfectly reasonable individual requests to the syntax like template specialisation. Only afterwards did the true nature of crawling horror that they'd inadvertently unleashed become apparent.

Java Swing using anonymous classes to 10 or more depths to represent callbacks because OOP and inheritance > all.

Haskell having one file IO operation a thousand feet below the surface of a program "un-purifying" the entire call stack with side effects because pure functional is king.

Trying to implement any generic anything in C, because in procedural having template or inheritance based polymorphic behavior is crazy, so you end up with 5 million ways to write readNumber() for every numeric type ever.

So go figure, procedural, meta, functional and OOP all go completely deep end when you try to kitchen sink them as the be all end all solution to all problems and woes.

The ternary operator in general eases understanding because it extracts the common bit, i.e. "sides[i] =", meaning you don't have to carefully read the contents of each and every conditional block to verify nothing else is going on besides this one assignment.

This example turns the code into something that appears more airy but in fact is much harder to understand due to extensive use of ? :.

I find that one of my own major steps toward programming maturity happened when I stopped doing goofy things like this and started writing code that was as simple as possible to logically follow, and that was as un-special-cased as possible. (By this latter I mean, if you change the code a little bit, you don't have to rewrite it; it looks basically the same. Imagine you want to do more than just assign one variable inside the clauses of the 'if'. In the Carmack version you just add more code there. In the proposed substitute, you have to rewrite the whole thing.)

You literally want to paint code, not write it. :)

This is a very good point that probably could be systematically exploited. Does anyone know examples of this?

If your description is accurate, Rust[1] is exactly what he wants. I've been learning Rust recently (with a little help from [2]) and it does a ton of static code analysis, is safe by default (no dangling or null pointers, no shared mutable state), uses Hindley-Milner type interface just like Haskell, and generally is what you would expect if Haskell and C++ had a baby.

[1] http://www.rust-lang.org/

[2] http://www.rustforrubyists.com/

  void up_front_decls()
  {
    float some_var;
    int another_var;
    
    some_var = get_some_var();
    do_some_calculations(some_var);
    maybe_something_else(&some_var);
    
    some_var = get_another_var();
    do_some_other_calculations(another_var);
    blah_blah_already_broken();
  }

  void as_needed_decls()
  {
    float some_var = get_some_var();
    do_some_calculations(some_var);
    maybe_something_else(&some_var);
    
    int some_var = get_another_var();
    // compile-time error
    // ...
  }

  void poor_style()
  {
    up_front            declarations;
    also                encourage;
    this_ridiculous    *block_style;
    that_is             a_royal_pain;
    to                  maintain;
    because_some_long_type inevitably;
    screws_it           up;
  }

If your function is five pages long, and in the fifth page you can't remember what's in scope and you have to reread through the entire function above, it might seem that having all variable declarations at the top would help, because you'd only have one place to look at. But the real problem there is that the function is too long, and it should be refactored instead.

I most certainly am const pedantic as well, and I was back when I worked on this project, too -- quite a few of the "inconsequential" lines I checked in were simply moving a variable declaration down to where it was initialized, and adding 'const'. I found the resulting code much easier to read.

If instead, a variable is assigned to only when it is defined, you're moving (in a small way) towards functional programming.

Also, I often use scope just control the lifetime of a resource. These look like meaningless braces in the middle of a function to the uninitiated. It's RAII.

    const int x = foo();
    // ...
    const int y = bar(x);

In C++ I'm a const nazi and declare where used to facilitate it, but if I'm writing C that targets the MSVC compiler (C89) where all variables have to be collected at the top of the inner scope I'll relax this as much as I have to.

Besides that, I think the stylistic changes this author is commenting on are fairly minor. I think the conciseness of vertical space was a bit confusing sometimes; this article only shows the simple functions where it works. The almost complete absence of templated is more likely because no STL code was used.

Certainly, the code base is very thorough. When I realized I had to use quaternions to represent the player's orientation in the game space, there was already an idQuat class ready and waiting and fully functional, which was very nice. I think that idQuat class was never even used anywhere in the base code, so it was cool -- for someone with who never knew about quaternions before then -- to have a class fully implemented and ready for me to use.

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.

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.

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

  // Toggle between Dropdown and Text
  if(_protected.fields[field].fieldType() === "Dropdown") {
  _protected.fields[field].set("fieldType", "Text");
    } else {
  _protected.fields[field].set("fieldType", "Dropdown");
  }

http://astyle.sourceforge.net/notes.html

I think Go is pretty unusual in that gofmt is provided with the language. So all Go everywhere looks the same. It's awesome isn't it? :)

I then just say, change it when you need it, and use that fancy "find usages" thing most IDEs and vim have.