Samuel's C++ Coding Style

File Comments

Each header file should begin with a asterisk comment box that states the classes fully qualified name, followed by a copyright notice of the form (C) 2007 by Your Name on the next line, followed by a blank line, followed by a concise description of the file. Since implementation files would effectively have the same beginning comment box, it can be ignored in the implementation.

Header Guards

The first two lines of every header file is a header guard. Although some files may not require this guard, using it consistently should help reduce errors. The header guard variable should be in upper case letters with underscores used as spaces, in the format FILENAME_H. A blank line should proceed the guard.

Includes

Because of the small number of includes in any given header file, there should be no blank lines between them. There are blank lines before and after the includes though. The includes are ordered from the most general system ones to the most specific user includes.

Namespaces

Namespaces are all lower case. If a name must be multiple words, underscores should separate them. To prevent the global namespace from becoming polluted, everything should be defined within an appropriate namespace and members should be qualified on each use.

Lines

A line can be up to 80 characters long and no longer. Some consoles are only able to display up to 80 characters per line and this allows them to view the source code without awkward line breaks. If a line must be split, this should be done in the most natural place for the situation. Also, the orphaned line should be indented to whatever seems best for the situation at hand. If a method is quite short, the entire method may be placed on a single line for a compact look.

Indentation

Indentation should be composed by two spaces each. This prevents different programs and their different numbers of spaces that make up a tab from messing up the code's alignment. This is the minimum amount to make an easily noticeable difference in indentation. It is also a small number which allows the most code to be written per line without breaking the line.

Braces

Opening braces are always located at the end of another line of code. This is because closing braces sometimes have instantiated variable names directly after themselves, also on the same line. A brace should be before and after a tiny single line method, on the same line, without any spaces between the line's text and the surrounding braces.

Parenthesis

Parenthesis are always preceded by a space, except if there is no argument list, for readability and consistency. Comma separated lists have a single space after each comment.

Variables

Variables should be entirely lower case with necessary spaces replaced by underscores. When variables appear in comma separated lists, pointer and reference modifiers should be immediately followed by their respective variable names without spaces.

Classes

The words and initials making up the name of a given class should start with capitals. Although single word classes are preferred, underscores should replace any necessary spaces. The access specifiers should be indented at the same level as the outer part of a given class itself. Groups of similar class members should be grouped together. The groups include variables, constructors and a destructor, mutators, accessors, and action methods. Each group should be separated by a blank line for readability. Due to the generalised nature of overloaded operators, they should appear first in their respective groups.

Nested Class Comments

The lines immediately before a nested class should form a comment box similar to the one at the beginning of the file, except that no copyright notice is given this time around.

Naming

Method names should be verb focused. Conversion methods should be prefixed with "to_". Methods that retrieve part of the associated object's state should be prefixed with "get_". An exception is boolean accessors which should be begin with "is_". Mutators should start with "set_".