From OpenVZ Virtuozzo Containers Wiki
Naming Conventions
- Names should be readable, better to do not use abbreviations
- CamelCase for names. Class, namespace, enum names should start with uppercase (for example, Audit). Other names should start with lowercase (Audit->getValue())
- Typedefs should have "_t" or "_type" suffix (myFavoriteType_t)
- Member value should have "m_" prefix (m_store)
- Static member variable should have "s_" prefix (s_count)
- Global object should have "g_" prefix. Global static variable is global still -> "g_" prefix
- No value type hints in a variable name or return type hints in a function name
- Local variables names should be short
- Class and namespaces names should consist of 1 or 2 words (Audit, AuditValue, but not AuditValueForTransition)
- Function name should start with a verb, because any function implies an action (getValue())
- Accesser name should start with "get", mutator name should start with "set" (getValue()/setValue())
Formatting Conventions
- It is highly desirable to follow the restrictions:
- line length is below 80 symbols,
- function body (outer) is below 50 lines
- '{' is on the same line with "if", "for", "while"
- Single-line nested block - without braces
- There should be a C++-style comment ("// comment") at:
- closing '}' for a namespace should have a comment about the namespace
- #else, #endif, #elif - a comment about a condition of the very first #ifdef
- One operation (ended by ';') per line
- Preferred order of a class labeled sections inside the class declaration:
- public
- protected
- private
- Preferred order inside a section:
- typedefs
- constructors
- destructor
- member functions
- static functions
- member variables
- static variables
- Empty line after every section inside a class declaration
- No empty line after the last section inside a class declaration
- No indent inside namespace
- Header files:
- No "using namespace ..." inside header files
- if a header file is a part of public API:
- use 'extern "C"' construct
- comments for doxygen MUST be
Taboos
- We do not use RTTI (no dynamic_cast<>)
- We do not use exceptions
- We do not use syntax allowed by C++11 standard
- We do not use conversion operators (int())
- We do not use assembler inlines
- We do not use "friends"
- We do not use "public" or "protected" member variables
- We do not use standalone functions (not bound to some class)
Other Rules
- A function, which results only in a success or failure, should use 'boolean' return type. In a case of "success", it should return "true".
- A function, which results in a custom error, should return PRL_RESULT return type.
- For a successful result, use PRL_ERR_SUCCESS
- A check of successful result of this value should be performed by PRL_SUCCEEDED() or PRL_FAILED() macros.
- It is highly desirable to avoid function definitions with more than 3 arguments. Allowed exceptions - external callbacks, interfaces, legacy functions.
- Use references to objects rather than pointers, even for smart pointers.
- Group related classes to a single namespace
- We do not welcome a polymorphic inheritance
- If possible, avoid manual memory management (use of "new" and "delete" operators)
- If possible, avoid low-level thread management API ("pthread_xxx"), better to use boost or QT wrappers over it.
- Use anonymous namespace for symbols, which should be defined and used only inside a local compilation unit.
- If possible, avoid use of complex boolean conditions. '==' is better than '!=', '<' is better than '>='
- We do not welcome a function with a boolean argument, which changes the function's behaviour