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

Post by daemin » Tue, Jan 15, 2013, 11:30 PM UTC

npsimons wrote: post #187

daemin wrote: post #131

Earlier quoted context omitted.

Some arguments in favour of getters and setters are; that using a function allows for the addition of caching, addition of thread safety checks, changing to compute the variable rather than store it, addition of logging, mapping it to be generated from another variable, etc.

I understand all of those justifications. When I mentioned changing implementation in my post, I was thinking of exactly those sorts of things. But none of them seem to be applied in the general case of "make a pass-through getter and setter for every member variable". My biggest question to the answer of universal getter/setters is "what is being abstracted?" Classes (and objects) are meant to abstract things like a…

Post by eru » Wed, Jan 16, 2013, 2:55 AM UTC

zanny wrote: post #119

rwallace wrote: post #88

Earlier quoted context omitted.

Any style of programming can look like a mistake if you take it to crazy extremes. I find header/template C++ programming works very well provided you do it in moderation and keep things simple. Remember the STL is complicated because it tries to be super generic, and it tries to be super generic because it's a library so it tries to cater for all possible uses. If you're writing a program instead of a library, you c…

For other examples of crazy extremes, see : 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 in…

Post by eru » Wed, Jan 16, 2013, 3:17 AM UTC

coffeeaddicted wrote: post #127

npsimons wrote: post #98

Earlier quoted context omitted.

I'm kind of the same opinion as Carmack re: getters/setters. My feeling is, if all you're going to do is allow clients to read and write the variable, why not just expose it? Sure, you can argue encapsulation and even justify it by saying that later down the road you may want to change the implementation, but far too often I've seen C++ classes with a setter and getter for every variable, for no good reason (eg, they…

One (maybe stupid?) reason why I really like getter/setters has nothing to do with encapsulation, but that it makes it easier to search for places where a variable is changed. Often you have lots of getFoo and little setFoo functions - so just searching for "Foo" will return lots of results while "setFoo" helps me finding those faster.

Post by nostrademons » Wed, Jan 16, 2013, 4:53 AM UTC

wtracy wrote: post #116

dpark wrote: post #25

Earlier quoted context omitted.

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…

I would argue that if declaring up-front versus declaring as-needed makes a significant difference in readability, then your functions are too long.

  for (int i = 0; i 

  int i;
  // Half a dozen lines
  for (i = 0; i