Coding style

From Medusa: Coordinate Free Mehless Method implementation
Revision as of 20:51, 15 November 2017 by Jureslak (talk | contribs) (Comments)

Jump to: navigation, search

This is a brief description of our coding style, roughtly following the Google C++ Style Guide. You can also download our code style settings to import in CLion: File:mm.xml. It can be imported under Settings/Editor/Code Style/Scheme/Import scheme.

General

A soft $80$ characters line width limit.

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 Moving Least Squres (MLS) 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.