Difference between revisions of "Coding style"

From Medusa: Coordinate Free Mehless Method implementation
Jump to: navigation, search
(Comments)
Line 52: Line 52:
  
 
<syntaxhighlight lang="c++">
 
<syntaxhighlight lang="c++">
// This function will change the world
+
// This function will change the world.
 
double change_the_world(bool skynet) {
 
double change_the_world(bool skynet) {
 
     if (skynet) {
 
     if (skynet) {
         return 0.0;  // Brace for the end of the world
+
         return 0.0;  // Brace for the end of the world.
 
     }
 
     }
 
     ...
 
     ...

Revision as of 21:49, 15 November 2017

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.

// This function will change the world.
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.