GG development team coding philosophy?

#1 Well. "It depends" fits pretty well. Not *everything* is that clean, but when I do things I just try to write it so someone will understand it without excessive comments. And if I had to think about the line of code I was writing for more than a minute it probably needs commenting. The 20 line long thing applies in some cases, not in others, I try to use inlines to do things I need to do more than once, etc. I'm one of the style nazis at GG, actually. I have an obcessive-compulsive need to put spaces in 'if' statements, like:
if(blah==3)
drives me crazy, so any piece of code I work on I make it look like
if( blah == 3 )
and am the same way about parenthesis in math operations.

#2 Coding styles are like religeons:

1) Everyone's got one (whether they realize it or not)
2) Discussing their relative merits is going to register extremely low in the "signal/noise" meter
3) MINE IS RIGHT. Die heretic!

#3 4) Your coding style is only right if it's identical to mine
5) Spaces suck. Tabs rule.

There goes another can of worms ;-)

#4 "And if I had to think about the line of code I was writing for more than a minute it probably needs commenting"

that's a great rule of thumb...

#5 "Write code so that your grandmother can understand it" or "Let the 'clever' be the final product, not in a line of code".

Ho hum, back to it.

- Melv.

#6 I rewrote a function yesterday that was, basically a big switch statement and 2 if blocks so that it used no branches at all. I think the comments are almost as long as the code. It's pretty interesting to say the least.

#7 5) Spaces suck. Tabs rule.

This is incorrect. Spaces rule. Tabs suck.
I personally WILL NOT put code into HEAD that is tabbed. We work on multiple platforms in multiple editors and tabs can screw the formatting up.

#8 Be consistent and don't be afraid to revisit code to make it cleaner... (Of course, make sure you know what you're doing - don't want to BREAK things that way! :)

I often find myself going through code that's already written and commenting it. It cleans the code up, conforms it to the "Torque style," and leaves good bread crumbs for later learners.

As far as code style goes, the most important thing is to be consistent. It's all pretty arbitrary in the end, just do it the same way all 'round. :)

#9

Quote:if(blah==3)
drives me crazy, so any piece of code I work on I make it look like
if( blah == 3 )
and am the same way about parenthesis in math operations.

Now I know who to blame for those thousands of lines I had to remove those space from, lol.

Quote:4) Your coding style is only right if it's identical to mine
5) Spaces suck. Tabs rule.

Absolutely right, preach on brother.

Quote:This is incorrect. Spaces rule. Tabs suck.
I personally WILL NOT put code into HEAD that is tabbed.

Whooops! (Note to self:Cancel all code submissions to the SDK)

#10

Quote:
I personally WILL NOT put code into HEAD that is tabbed. We work on multiple platforms in multiple editors and tabs can screw the formatting up.

That is something different entirely, which makes me add:

6) When working with an existing codebase, you adapt yourself to the existing code, you do not adapt the codebase to your style.

Anyone ignoring rule #6 deserves the hell that they receive for it :)

T.

#11 Tabs are great if you control all the tools. But if you don't, spaces are the most portable. Try viewing tabbed source in a web browser (such as through ViewCVS). Now go fix Mozilla and convince MS and Opera to fix theirs to do whatever it was you intended.

Well-written code will tell you how something works. Comments tell you why it was written that way instead of using some other algorithm.

While I adapt to the code base, I prefer "if (condition)" or "for (loop-term)" (space between control construct and paren but not inside paren). And spaces around every operator. ("if" and "for" are not function calls.)

I love the ternary operator when the left side of an assignment in two "if" branches is the same. Instead of:

if (condition) foo = true-value; else foo = false-value;

I use:

foo = condition
? true-value
: false-value;

(My editor will align the 3 parts, and I imagine "?" to mean "then" and ":" to mean "else".)

This is esp. nice when the two assignments are large and only a tiny part is affected by the conditional, as it makes it clear which part is changing.

Parameters to word operators like "return" and "sizeof" should not be parenthesized. (But note that a type passed to sizeof must be parenthesized; the parens are part of the type syntax, not a fake function call syntax.)

char foo[20];
memset (foo, 0, sizeof foo);

#12 Thanks for the kind words. :) Torque is far from the cleanest code ever, but it works and it's pretty darn good lookin'. I don't think we have any major philosophy about it, other than to be careful about how you code. There are certainly no hard and fast rules. Not to brag, but the main reason it's as clean as it is is mostly just that good coders work here (and good coders in the community contribute!), and all of us have lots of experience working in large code projects (even those of us who are young). We all care about the style of the code and how easy it is to follow. For example, before I ever made my first change to the Torque codebase, I forwarded it along to Ben and asked him if my style was inkeeping with the general Torque style. Besides knowing that lots and lots of customers will be reading our code, we also all know how painful it is to re-visit code that is hard to understand, especially in a big, complex project.

On code style debates, I just have one thing to say: spaces > tabs. For Torque this is not debatable... we all use different editors, on different platforms, and man oh man do tabs cause frustration for everyone.

#13 I suspect most tab advocates use tools that don't distinguish between the tab key and the tab character, and that use tools that don't do good automatic indent/alignment. My editor (an Emacs clone) will automatically indent a line when I hit the tab key, but do it with my choice of spaces or tabs. Operationally, it doesn't matter to me which character is in the file. However, tabs characters create grief when one uses other tools that have a different idea of the tab's width, or when one switches among several vendors' code, each with its own idea of the width of a tab. Now you could propose some kind of metadata describing the width of the tab, but that way leads to madness: The next thing would be XML as a source format, with a DTD for every programmer! :)

#14 I'm a non-tabber myself. After being forced to use many different dev tools and lots of legacy code, you learn to be very wary of anything with tabs in it.

#15 Tab = bad
Cola = good

What? We're not talking soft drinks?

#16 Gimme a coke!

#17 Personally, I'm a tab man... but I lost that argument with Rick and Tim, oh 10 years ago.

:D

#18

Quote:
Mark Frohnmayer said:
Personally, I'm a tab man... but I lost that argument with Rick and Tim, oh 10 years ago.

But only because you're wrong. >:)

Kenneth has it nailed. It doesn't matter whether you're using tabs or spaces until you open a file in an app other than the one it was written in. In that case, tabbed code almost universally looks awful, while spaced code looks fine-n-dandy. It's a courtesy thing. Be kind to your fellow programmers. Use spaces.

Most programming editors support "tab key = N spaces" and "ctrl+arrow = move cursor to next word". With these two in place, the number of keystrokes becomes identical. Ctrl+arrow can have an advantage over tabs... when there's more than 1 tab (3+ isn't uncommon in Real Code) rather than arrowarrowarrowarrow, you just hit ctrl+arrow. Badabing, badaboom.

Many of these things boil down to personal prefference, but in this case, there are concrete reasons to go with spaces that can't be countered by the tab zealots (who are wrong).


And I preffer Dr Pepper myself. Yes, I choose the mass-produced sugar water that caters to people who want to be individuals! Yay me. Stupid marketing, good flavor.

#19 I used to be a tab man.. but now I'm a space man. A space is a space is a space... whereas a tab is 3, or 4, sometimes 2 but never 1... it's just too wishy-washy.

BTW, Pat... the only way to write true if statements:

if(myVar!=5)yourVar=2;else myVar=yourVar;

Yummy...
- Brett

#20 Ah yes... clever code.

Some nigh-famous programmer once said "You have to be twice as smart to debug code as you do to write it, so any time you write your cleverest code, BY DEFINITION, you are incapable of debugging it". Almost certainly not the exact words, but the spirit is there:

Clever code is buggy code. And be kind to the fresh-out grad that has to maintain your code oh Language Guru: Write Simple Code.

Not that I don't violate that last bit regularly, being a junior C++ Guru myself:

I'm actively inflicting the STL on all my coworkers. Even gave a little presentation, with a nice dose of www.boost.org thrown in for good measure. If it's a standard part of the library, people should be expected to know it. Many do not, but that' hardly MY fault now is it? >:)