Coding Policies

Table of Contents


General policies

Coding style

This section is loosely based on (CC-By 3.0 License)

General rules


  • No tabs should be used. Indentation must include 4 spaces.


  • Function names, variable names, and filenames should be descriptive; avoid abbreviation. Types and variables should be nouns, while functions should be "command" verbs.

Specific rules


  • Filenames should be all lowercase and may include underscores _.
  • Extensions of C++ source and header files should be .cpp and .h respectively.

Type names

Names of all types – classes, structs, typedefs, and enums – have the same naming convention:

  • Type names start with a capital letter and have a capital letter for each new word, with no underscores: MyExcitingClass, MyExcitingEnum.


  • All enumerations must be defined within some container class scope.
  • Names of the enumerators should be in upper case with underscores.


  • Variable names are all lowercase, with underscores between words, i.e., my_table_name.
  • Global variables must be avoided. If it is not possible, their names must have g_ prefix, e.g., g_my_global_variable.

Functions and methods

  • Functions should start with a lowercase letter and have a capital letter for each new word without underscores.
  • Function names should typically be imperative, i.e., they should be commands: openFile().
  • Parameters, which do not serve as outputs, must be marked with const.
  • Output parameters must be gathered in the beginning of the list of parameters: doSomething(output1, output2, input1, input2 = <default_value>).


  • It is not allowed to mix definitions with different access modifiers, i.e., methods and members with the same access modifier should be gathered together.
  • It is recommended to use access modifiers multiple times to visually separate members from methods.
  • Names of member variables should have trailing underscores, i.e., member_name_.
  • Methods, which do not change the corresponding class, must always be marked with const.
  • In general, destructors of base classes must be defined and must be protected. If it is necessary to allow polymorphic destruction, the destructor should be defined as public and virtual.
  • Constructors of base classes should be protected as well.


  • Macro should be avoided when possible.
  • Macro name must be in all capitals with underscores.


  • Names of namespaces should be in lower case with possible underscores.


  • Names of template parameters should follow the same conventions as the category they belong to (typenames, variables), but their names must include t_ prefix: t_BaseClass.

Visibility of symbols

Implementing tests