Each header and source code file will have a code template which will consist of a common included header (for compilers that support it, this will be used as the pre-compiled header containing standard library includes), and the copyright notice with GPL statement.
Indents will be used as 2 spaces. Horizontal spacing and braces-on-their-own-line will be defined by the author of a particular header or source file as long as it is reasonable, and the same format is used consistantly throughout a single file.
Header files will also include the code template, but their first three lines and the last line will be used for guarding against multiple inclusion:
#ifndef _HEADERFILENAME_H_
#define _HEADERFILENAME_H_
/** copyright notice.... */
#include "egstank.hpp"
... header code ...
#endif
C++ include files will be named as .hpp. Tradtionally most people have been using .h files but now the standard is moving towards .hpp for C++ include files to provide more language hints to the compiler and because of name conflicts with common C and compiler-specific include files, espically on case insensitive file-systems like Windows (I had this problem with my networking library that I had to readjust my entire include structure).
The main documentation for this project will go into the header files, and will be javadoc style. Comments that use the \todo or \bug tags for doxygen will go into the main code file (.cpp).
Source files will implement the functions defined in the headers, preferably in the same order as they are declared in the header files.
Correctness before optimization. Do not do any premature optimization. Focus on creating a bug-free and readable product before you attempt to optimize it before you know how much resources it takes. Therefore you should try to stay away from inlining functions (in the headers) even for small constructors and accessors, and use the standard C++ library where possible. If we find performance bottlenecks we will fix them later.
Public methods will be defined before private methods, as this makes the header easier to read. Public methods of a class should change as little as possible, and should be throughly documented, espically if other modules will be using it. Private methods should be documented but it need not be as verbose as public method documentation.
Public data members should be avoided at all possible, unless they are declared as const.
Classes should try to be const correct -- this better conveys the purpose of the method and can aid the compiler in optimizing the code. Using const also reduces errors in class code by allowing the compiler to find more of your mistakes. If a class method does not modify the class, it should be delcared as const.
In class constructors, member initializers should be used when possible. ie:
Class() { x=5; } vs Class() : x(5) {}
Classes should be named starting with a capital letter, and each word in the name also starts with a capital letter. The header file and implementation of a class or namespace should be the same name as a class. For example, for a class called MoveableTankTurret, the header is MoveableTankTurret.hpp and the source file will be MoveableTankTurret.cpp.
Methods and data members of a class should be named with a lowercase letter, and each extra word will start with a capital letter (ie drawLine).
C-style code and functions should be in a namespace to help avoid namespace conflicts with other classes and libraries that we use that do not use namespaces. Namespace headers and implementation files should be named like classes, and an appropiate namespace name should be picked for a set of instructions.