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.