guidelines

C++ Programming Guidelines

We base our style and best practice guidelines on the ones at geosoft.no with a few modifications.

• Syle guidelines (Mirrors: pdf html)
• Best practice (Mirrors: pdf html)
• [Additional C++ programming guidelines](google style guide)

Style guideline modifications:

• 11. Don't use the underscore _ suffix for private members.

• 24. We use the Id suffix instead of the No suffix.

• 34. We use the file extensions .cpp and .hpp.

• 36. In some cases it might be permitted to define methods in the header files (e.g. when templating)

• 58. break and continue are permitted.

• 70. Use nullptr for Null-Pointers instead of 0 or NULL

• 75. For the else block, either put opening and closing bracket on the same line or both on separate lines:

    // DO:
    if ( ) {
      // do something
    } else {
      // do something else
    }
    
    // DO:
    if ( )
    {
      // do something
    }
    else
    {
      // do something else
    }
  
    // DON'T: (don't mix it up)
    if ( ) {
      // do something
    }
    else {
      // do something else
    }
  

• 81. Same thing as in 75. (see above)

• 83. Don't put the function return type on a separate line.

• 85. Don't put a space between the function name and the first (. DO: foo(bar), NOT: foo (bar).

• 90. - 94. We use Doxygen style comments.

Practice guideline modifications:

• 10. If no copy constructor and/or assignment operator is defined, disallow those operations by declaring but not defining a private copy constructor and assignment operator. This can be done with Google's DISALLOW_COPY_AND_ASSIGN macro.
• 16. The == and != operators don't always need to be implemented .

Additional best practice policies/guidelines

Additionally to the practice guidelines from geosoft.no we use part of the Google C++ Style Guide:

• See our [Additional practice guidelines](google style guide)