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

Post by jgeralnik » Mon, Jan 14, 2013, 9:55 PM UTC

dpark wrote: post #25

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.

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

  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;
  }

Post by Tyr42 » Mon, Jan 14, 2013, 10:02 PM UTC

dchichkov wrote: post #53

Cushman wrote: post #50

Earlier quoted context omitted.

Bravo. That comparison makes worrying about vertical space seem ludicrous.

Space is important. Think that you are not writing code, but painting a picture. And you are using space to convey meaning. You literally want to paint code, not write it. :)

Post by forrestthewoods » Mon, Jan 14, 2013, 10:04 PM UTC

linhat wrote: post #69

zem wrote: post #45

Earlier quoted context omitted.

> A lot of the practices here are enshrined in the Google C++ styleguide: with the notable exception of lining up things horizontally, which tends to be frowned on.

I really do not understand why they chose to do so. In my opinion, it does not improve readability at all, even worse, when the spacing between type and name gets big , your eyes need more work to figure out the correct line relations. Furthermore, this can generate horrible commits, for example: int x; int y; becomes: int x; int y; float z; after adding ONE single variable. But your commit will contain changes for t…

Post by Tyr42 » Mon, Jan 14, 2013, 10:14 PM UTC

mercurial wrote: post #55

nirvdrum wrote: post #43

Earlier quoted context omitted.

IntelliJ has inspections for long class and method names. A lot of Java devs run that. Long names are frequently derided in the Ruby community as being Java-like. I can't speak to Haskell at all. But generally whenever something needs to be typed frequently, it tends to be shortened. My favorite is when vowels are deemed too onerous.

Haskell is a special beast, in the sense that it uses single letters a lot for generic types in signatures. Eg: doFoo :: a -> a where doFoo will take any type a and return something of the same type. Due to the density of the language, you'll often find plenty of small, commented functions.

Post by jblow » Mon, Jan 14, 2013, 10:18 PM UTC

Garoof wrote: post #63

jblow wrote: post #51

Earlier quoted context omitted.

Ugh. I prefer the Carmack version. 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 thi…

I like the last one better. I think it reads more like "assign one of these values to sides[i]" and less like "do one of these three things". "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." I'd say that's kind of the point though. The first one would look "basically the same" if in the last else it assigned to sides[j] instead of sides[i]. In th…