C++ Code Style Guide

Naming Conventions

1. Names should be readable, better to do not use abbreviations
2. CamelCase for names. Class, namespace, enum names should start with uppercase (for example, Audit). Other names should start with lowercase (Audit->getValue())
3. Typedefs should have "_t" or "_type" suffix (myFavoriteType_t)
4. Member value should have "m_" prefix (m_store)
5. Static member variable should have "s_" prefix (s_count)
6. Global object should have "g_" prefix. Global static variable is global still -> "g_" prefix
7. No value type hints in a variable name or return type hints in a function name
8. Local variables names should be short
9. Class and namespaces names should consist of 1 or 2 words (Audit, AuditValue, but not AuditValueForTransition)
10. Function name should start with a verb, because any function implies an action (getValue())
11. Accesser name should start with "get", mutator name should start with "set" (getValue()/setValue())

Formatting Conventions

1. It is highly desirable to follow the restrictions:
   1. line length is below 80 symbols,
   2. function body (outer) is below 50 lines
2. '{' is on the same line with "if", "for", "while"
3. Single-line nested block - without braces
4. There should be a C++-style comment ("// comment") at:
   1. closing '}' for a namespace should have a comment about the namespace
   2. #else, #endif, #elif - a comment about a condition of the very first #ifdef
5. One operation (ended by ';') per line
6. Preferred order of a class labeled sections inside the class declaration:
   1. public
   2. protected
   3. private
7. Preferred order inside a section:
   1. typedefs
   2. constructors
   3. destructor
   4. member functions
   5. static functions
   6. member variables
   7. static variables
8. Empty line after every section inside a class declaration
9. No empty line after the last section inside a class declaration
10. No indent inside namespace
11. Header files:
    1. No "using namespace ..." inside header files
    2. if a header file is a part of public API:
       1. use 'extern "C"' construct
       2. comments for doxygen MUST be

Taboos

1. We do not use RTTI (no dynamic_cast<>)
2. We do not use exceptions
3. We do not use syntax allowed by C++11 standard
4. We do not use conversion operators (int())
5. We do not use assembler inlines
6. We do not use "friends"
7. We do not use "public" or "protected" member variables
8. We do not use standalone functions (not bound to some class)

Other Rules

1. A function, which results only in a success or failure, should use 'boolean' return type. In a case of "success", it should return "true".
2. A function, which results in a custom error, should return PRL_RESULT return type.
   1. For a successful result, use PRL_ERR_SUCCESS
   2. A check of successful result of this value should be performed by PRL_SUCCEEDED() or PRL_FAILED() macros.
3. It is highly desirable to avoid function definitions with more than 3 arguments. Allowed exceptions - external callbacks, interfaces, legacy functions.
4. Use references to objects rather than pointers, even for smart pointers.
5. Group related classes to a single namespace
6. We do not welcome a polymorphic inheritance
7. If possible, avoid manual memory management (use of "new" and "delete" operators)
8. If possible, avoid low-level thread management API ("pthread_xxx"), better to use boost or QT wrappers over it.
9. Use anonymous namespace for symbols, which should be defined and used only inside a local compilation unit.
10. If possible, avoid use of complex boolean conditions. '==' is better than '!=', '<' is better than '>='
11. We do not welcome a function with a boolean argument, which changes the function's behaviour