Previous topic

Miscellaneous rationales, ideas, notes

Next topic

Code organization

Coding-style conventions

  1. Reserve struct for TMP (traits classes, metafunctions, etc.) and stateless classes, otherwise always use class

  2. Names representing types must be in mixed case starting with upper case

  3. Variable names must be in mixed case starting with lower case

  4. Private class variables must have underscore suffix (this makes them easier to spot than the underscore prefix.)

  5. Named constants (including enumeration values, and template parameters of integral const type) must be all uppercase using underscore to separate words — Enumeration constants must be prefixed by a common type name

  6. Names representing methods or functions should be verbs and written in mixed case starting with lower case — They are distinguished from variable names anyway by their special syntax

  7. Names representing template metafunctions must be named as if they were functions, but in mixed case starting with upper case as if they were types

  8. Names representing namespaces should be all lowercase

  9. Names representing template types should be a single uppercase letter

  10. Generic variables should have the same name as their type — Non-generic variables have a role: these variables can often be named by combining role and type

  11. Variables with a large scope should have long names, variables with a small scope can have short names

  12. The name of the object is implicit, and should be avoided in a method name

  13. The terms get/set must be used where an attribute is accessed directly — This, together with items 2, 3, 4, 6, and 10, allows for very convenient naming, eg:

    class Foo
    {
    public:
      Foo(Bar bar) : bar_(bar) {}
    
      bar  getBar(       ) const {return bar_;}
      void setBar(Bar bar)       {bar_=bar   ;}
    private:
      Bar bar_;
    };
    
  14. Plural form should be used on names representing a collection of objects

  15. The prefix n should be used for variables representing a number of objects

  16. The suffix No should be used for variables representing an entity number

  17. Iterator variables should be called i, j, k etc.

  18. The prefix is should be used for boolean variables and methods

  19. Naming pointers specifically should be avoided

  20. Negated boolean variable names must be avoided

  21. Exception classes should be suffixed with Exception

  22. Functions (methods returning something) should be named after what they return, procedures (void methods) after what they do

  23. C++ header files should have the extension .h, source files can have the extension .cpp or .cc

  24. Header files must contain an include guard. The guard macro name should be the all-uppercase filename including the path relative to the project root with . and / replaced by _ and with the suffix _INCLUDED. It must not start with an underscore.

  25. Include statements should be sorted and grouped. Sorted by their hierarchical position in the system with high level files included first. Leave an empty line between groups of include statements. Cf. below in code organization

  26. Include statements must be located at the top of a file only

  27. The parts of a class must be sorted public, protected, and private. All sections must be identified explicitly. Not applicable sections should be left out.

  28. Abbreviations and acronyms must not be uppercase when used as name

  29. Complement names must be used for complement operations

  30. C++ pointers and references should have their reference symbol next to the type rather than to the name

  31. The nominal case should be put in the if-part and the exception in the else-part of an if statement

  32. Use alignment wherever it enhances readability

  33. Use // for all comments, including multi-line comments — then any larger passage can be commented out with /* ... */

  34. The function return type can be put in the left column immediately above the function name

  35. Consider using a beautifier (bcpp?)