Open Geometry Processing Library
If you would like to contribute to OpenGP please make sure your code adheres to the following coding conventions. For general best practices we recommend consulting the JSF coding standard available here.
The names of user-defined types (such as classes, structs and enums) are begin with a capital letter. Words within the name are written camelcase. Acronyms are written in all capital letters. The names of persons such as Cholesky or Delaunay are properly capitalized as well.
Function names are written in lower-case letters only. Words within the function name are separated by underscores.
Variables are named in lower-case letters only. Words within the variable name are separated by underscores. Member variables have a trailing underscore as a prefix (suffix: obsolete).
File names follow the naming rules for user-defined types. Implementation files end with
.cpp and header files end with
SparseMatrix.cpp for the implementation file.
SparseMatrix.h for the header file.
The expressions following an
if, else, while, do ... while or
for statement should always be enclosed in braces. The braces enclosing a block should be placed in the same column, on separate lines.
C++-style comments should be used, i.e.
// My important comment.
Lines should not exceed more than 80 characters. There should only be one statement per line.
Use spaces instead of tabs. Indent the code by four spaces for each level of indentation. Avoid trailing whitespaces at the end of a line as well as on empty lines.
This section describes some basic programming conventions developers should adhere to in order to avoid common pitfalls.
Use header guards in order to protect against multiple inclusion. We use #pragma once which is widely adopted by many modern C++ compilers. For the file YourClass.h the header guard should look like this:
Use the OpenGP namespace in order to avoid conflicts. In source files, do not add an additional level of indentation due to the namespace:
These commands will re-compile and then update the documentation published on GitHub:
Alternatively, this is conveniently wrapped by the following: