Coding style

This is a brief description of our coding style, roughtly following the Google C++ Style Guide.

You can also download the CLion settings: File:Settings.jar, which you can import in File/Import settings.

You can also download only our code style settings to import in CLion: File:mm.xml. It can be imported under Settings/Editor/Code Style/Scheme/Import scheme.

General

We use a 100 characters line width limit in C++ code.

Indentation

Indent using spaces. Indentation width is 4 spaces.

for (int i = 0; i < 10; i++) {
    cout << i << endl;
}

Naming convention

Constants - UPPER_CASE

classes - PascalCase

methods - camelCase

variables and stand-alone functions - underscore_separated

typedefs - lowercase underscore separated, usually one word with trailing _t, eg. vec_t.

namespaces - one lowercase word, maybe shortened, eg. op. For internal implementation details use op_internal. Namespace closing brace should contain comment `// namespace your_name`. There is no indentation within namespaces.

All standard abbreviations like Weighted Least Squares (WLS) or Finite Elements Method (FEM) - UPPER_CASE

Floating point and integer literals use small suffixes, eg. 0.0f, -1e8l, 45ull .

#define MAX_VALUE 500
class MyClass {
  public:
    MyClass(first_var, second_var) {
        ...
    }
    int getSize();
}

Comments

Comments are good. Use them to explain your code. Comments should have a space between the last slash and the start of text. Inline comments should have at least two spaces between end of code and start of the comment. Comments before functions are used for documentation. Always use full sentences and end them with a punctuation mark.

/**
 * This function changes the world.
 * @param skynet If `true`, the world ends, otherwise nothing happens.
 */
double change_the_world(bool skynet) {
    if (skynet) {
        return 0.0;  // Brace for the end of the world.
    }
    ...
}

Use doxygen comments to generate documentation.

Headers

All headers must contain a header guard of form PATH_TO_FILENAME_HPP_ as enforced by the linter.

Includes in header guards are separated in two groups, with intra-project includes on top and other includes on the bottom. The groups are separated by a blank line and includes are kept sorted within a group.

Misc

Avoid trailing whitespace. Curly opening brackets { should be inline with for loops, function definitions, class names, separated with a space. Outermost binary operators should have spaces around them.

int sumMe(int var) {  // yes
    if (var == 1)
    {                 // no
        return 1;
    }
    return 0;
}

For null pointer we use nullptr instead of NULL macro.

Using your IDE auto formatter

Most available IDEs support source code formatting using clang-format. We recommend using coding style based on Google, with minor modifications concerning indentation and pointer location.

# Use the Google style in this project.
BasedOnStyle: Google

# Custom adjustments.
AccessModifierOffset: -2
IndentWidth: 4
ColumnLimit: 100

# Some folks prefer to write "int& foo" while others prefer "int &foo".  The
# Google Style Guide only asks for consistency within a project, we chose
# "int& foo" for this project:
DerivePointerAlignment: false
PointerAlignment: Left

# Do not sort includes.
SortIncludes: false

More information about auto formatting in:

• Visual Studio Code,
• Jetbrains Clion