There are an unlimited number of styles that can be used to write code, and in many cases the pros & cons for any two approaches balance one other out. At the same time, we believe that it is important to maintain consistent styles and practices to improve readability and make the code easier to understand.
These are the current policies we have adapted for Pion:
- Indent using TABS, not spaces
- Use "camelcase" for class names (capitalize first letter of each word)
MyClassName - Use "camelcase" for member functions (same as class names except first letter is lowercase)
aFunctionThatDoesSomething() - Use lowercase for all member variables, separate words with underscores, and prefix the name with "m_"
m_variable_name - Same for variables on the stack, except without the prefix
variable_name - Append "_ptr" or "_ref" for pointers and references, respectively
variable_name_ptr - Use all caps for static constants, separate words with underscores
VARIABLE_NAME - Try to use typed class members for all static constants versus preprocessor statements
class MyClassName {
static const unsigned int VARIABLE_NAME;
}; - Use all caps for preprocessor macros, separate words with underscores, and prefix with "PION_"
#define PION_HASH_MAP std::hash_map - All public members (functions, variables, and data types) must be documented using Doxygen compatible style, and describing all arguments and the return value (if any)
- It is recommended that all other members are documented as well
- All implementation code logic must include descriptive comments unless it's extremely trivial
- Use inline functions when it makes sense to avoid stack overhead, from an optimization standpoint (this is not always easy, so do NOT use inline if you are unsure -- it can always be made inline later)
- Inline functions of less than a few lines may be included within the class declaration. Anything longer should be be placed following the class declaration in the same header file.
