Indent width: 4 spaces

Why: 2 is too hard to distinguish levels of indentation.  8 is probably
overkill, and it becomes difficult to read a 3+ level indented line on an
80-char wide terminal.  Tabs should be avoided as they are displayed
differently on different editors.

---

Case labels and class access specifiers should not be indented.

    switch ( bla ) {
    case 1:
        break;
    default:
        break;
    }

    class Bla {
    public:
        int i;
    };

Why: They're always there, so there's no need to set them off from the
rest.  It would be a waste of horizontal space to indent everything an
extra level beyond the access specifier or case label.

---

Put start braces on same line as flow control (if, else, class, while,
etc), except for functions.  Put end braces on their own lines.

    if ( bla ) {
    	...
    }

    else {
    	...
    }

not

    if ( bla )
    {
    	...
    } else
    {
	...
    }

or any combination.

Why: A "{" on the same line does not interfere with readability, and a "{"
on a line by itself is a waste of a line.  Snuggling "} else {" is ugly and
inconsistent with indentation rules, ie the "else" should line up with the
"if".  Functions are the exception, as having the "{" in the first column
helps parsers as well as humans recognize the beginning of function bodies.

---

Always use braces in if/while/for/etc, even when you can fit the
condition and the statement on the same line.

    if ( bla ) {
	command;
    }

not

    if ( bla ) command;

or

    if ( bla ) { command; }

Why: It's quite common to have to add extra commands inside an if/while/etc
body, and adding braces is both tedious and easy to forget.  Given our
braces guidelines, this only wastes 1 line of vertical screen space.

---

Function calls should not have spaces before the (.  if, for, etc, should.

    if ( something ) {
	func( something_else );
    }

Why: To make it obvious when you're calling a function.

---

Header guards:

#ifndef _FILE_H
#define _FILE_H

...

#endif // header guard

Why: standard header files usually use two leading _'s.  Comment the endif
as "header guard" because it's clear, and so you don't have to change it if
the filename changes.

---

Constructor initializer ':' should be on the same line as the constructor.
The initializers should start on the next line, and be indented once:

MainMenu::MainMenu() :
	title("Bling Bling"), help("Help"),
	etc("Etc...")

Why: If there are multiple lines of initializers, the ':' on the first line
will allow them all to line up in the same column (as opposed to putting
the ':' on the same line as the initializers).  Starting initializers on
the next line helps clarity.

---

Inside a class declaration declare things in the order:

  1. public
  2. protected
  3. private

Conceptually, friend operators are probably public, and internal friend
classes are probably private.

Why: The more likely people are to need something, the closer it should be
to the top of the list.

---

Inside a class access label, declare things in the order:

1. type declarations
2. static methods
3. ordinary methods
4. static member variables
5. ordinary member variables

Why: Consistency.  It's good if you know where to find things.

---

Function parameters should be separated by spaces from other parameters.

Furthermore, spaces should always be used around parentheses and operators.

Furthermore, template variables should be a declared with a trailing space
before the closing bracket.

func( arg1, arg2, arg3 );

and

for ( int i = 0; i < n; i++ ) {
	...
}

and

var1 = var2 / ( var3 + var4 - ( var5 + var6 ) );

and

vector< Object* > objects;
or
map< string, Object* > objects

Why: Longer statements and nested statements are difficult to tease apart
with operators and parentheses butted right up against variables.

---

Classes should be named in HungarianStyle, with each word capitalized.

Variables and functions should be all lowercase, and separated_by_underscores.

Macros and constants (#defines, enums, const int) should be ALL_UPPERCASE, and
likewise separated_by_underscores.

Why: To avoid naming clashes between variables and classes, and to make it
obvious which is which.

---

Private or protected variables and methods should be prefixed by a single
underscore.

Why: To emphasize which are private variables/methods.  This also makes it
more obvious which variables/methods are a class's internal data, vs which
are global data or stack variables.

---

When including header files, do so in the following order:

1. AP headers
2. system headers
3. ClanLib headers
4. Libgfx headers
5. ODE headers

Why: Consistency.  Including the AP headers first also allows us some control
over #define's and typedef's.

---

Commenting is to be done in JavaDoc style, so that we can use Doxygen.

/**
 * Brief description.
 *
 * Followed by a more detailed description.
 *
 * @param x description of x
 *
 * @return description of return value
 */

See http://www.stack.nl/~dimitri/doxygen/manual.html and Sample.[h|cpp] for
more information.

Why: Good documentation is invaluable, a standard commenting style ensures
that all programmers are able to read all comments.  And being able to
automatically generate documentation pages is very useful.