Style Guide

There are almost as many styles in coding a computer language as there are people using the language. Despite this, there are usually a few styles that serve as conventions that make reading (but not necessarily writing) code less tedious. Remember three rules: 1) You write code once, but people (including yourself) will need to read and comprehend it many times.
2) It is better to have a single standard that is a compromise among multiple developers (i.e. NOBODY gets EVERYTHING that THEY wanted) than to have no standard at all
3) NEVER use a coding style as a politcal tool.

General Lexical Rules

Use tabs for levels of indentation
Use at least two spaces to "sub"-indent continued lines
Attempt to keep line lengths down to what can comfortably fit within the primary editing tool your team (or you if you're going it alone) uses.
When spliting a single construct into multiple lines, try to split along "natural" breaking points, such as AFTER commas and closing parenthesis, and BEFORE quotes, and opening parenthesis
Put spaces after commas
Put spaces in between keywords and the opening parenthesis (e.g. "if (", "while (")
Do NOT put spaces in between a function's name and the opening parenthesis (e.g. "func(10);" )
Use a consistent identifier scheme. Some suggestions are: "Unix" Style - all identifiers are lowercase with words separated with underscores
Camelback - all identifiers have the first letter of each word uppercased, with all others lowercase
Lower Camelback - same as Camelback, but the first letter of the first word within an identifier is lowercase
Mixed Camelback - the use of Camelback for class names and Lower Camelback for object names Use a consistent brace placing scheme. Two main options are: Put braces on same line as construct: 
if (condition) {
	. . .
}
Put braces on their own line at same level as construct: 
if (condition)
{
	. . .
}
While the latter is more consistent, it wastes A LOT of vertical space and can detract from readability.
Whichever style you use, ALWAYS use braces even when there is only one statement.
In the case there is only one statement within braces, it is sometimes more readable to save space with using this style: 
{ statement; }
Used like: 
if (condition) { return; }
Empty scopes (e.g. bodies of constructors with no statements) may often be written as: 
{ }

Source File Organization

A source file should follow the outline: Preprocessor includes and defines
"using" statements
File scoped constant definitions
Type declarations and definitions
Global (eek!) object definitions
Function declarations and definitions Header File Organization A header file's organization is similar to a source file's with a few notable exceptions: Preprocessor includes and defines
using statements
Constant definitions
Object declarations Type declarations and definitions
NEVER any object definitions
Function declarations
Inline and/or template function definitions
NEVER non-inline or non-template function definitions

Class Style

Classes should be organized in the following fashion: Nested classes and other type declarations and definitions.
Static const class members
Member object declarations
Constructors
Destructor
Access functions
Other public member functions
Private member functions The class definition syntax should follow these guidlines:
class class_name {
public: // access control labels at same level as "class" keyword
	contents indented one level
};

Function Organization

Functions should be organized in the following fashion: Local type declarations
Local constant declarations
Function static objects definition
Function statements Function definition syntax should follow these guidlines: 
return_type function_name(
	arg1_definition,
	..
	arg_n_definition
)
{
	statements
}
In the case where all arguments can fit on a single line, then the following could be used: 
return_type function_name(arg1_definition, ..) {
	statements
}