OpenGP  1.1
Open Geometry Processing Library
Development Guide

Table of Contents

Coding Conventions

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.

Naming Conventions


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.

class SparseMatrix { ... };
enum RGBColors { red, green, blue };
class SparseCholeskySolver { ... };


Function names are written in lower-case letters only. Words within the function name are separated by underscores.

class ExampleClassName
double example_function_name(void);


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).

int globals_considered_harmful;
class ExampleClassName
double _member_variable_name;
static double _static_variable_name;

File Names

File names follow the naming rules for user-defined types. Implementation files end with .cpp and header files end with .h. Examples: 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.

if (foo_bar == baz){
std::cout << "hurz" << std::endl;
std::cout << "asdf" << std::endl;


C++-style comments should be used, i.e. // My important comment.

Line Length

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.

Programming Conventions

This section describes some basic programming conventions developers should adhere to in order to avoid common pitfalls.

Updating Published Doxygen

These commands will re-compile and then update the documentation published on GitHub:

~/Developer/OpenGP/build: make doxygen
~/Developer/OpenGP/build: cd doc
~/Developer/OpenGP/build/doc: git init
~/Developer/OpenGP/build/doc: git add .
~/Developer/OpenGP/build/doc: git commit -m "updated doc"
~/Developer/OpenGP/build/doc: git remote rm origin
~/Developer/OpenGP/build/doc: git remote add origin
~/Developer/OpenGP/build/doc: git push origin master --force

Alternatively, this is conveniently wrapped by the following:

~/Developer/OpenGP/build: make publish_doc