Revision 10 as of 2010-10-31 16:52:56

Clear message

Back to the HomePage.

Coding conventions



We follow the task-based workflow explained here. All significant development should be in response to an issue in the tracker, let's say issue1000. Then the usual development process involves two roles, "developer" and "reviewer" (usually Malte), and works as follows:

  1. Developer creates a new branch issue1000 in their own repository, usually branching off the newest revision in default. Note the exact spelling of the branch. Being consistent here allows us to automate some of these steps in the future.

  2. Developer resolves the issue in the branch. (Developer does not close the branch or push the changes to the master repository.)

  3. Developer sets the status of the issue to "reviewing".
  4. Reviewer pulls the issue1000 branch into their own repository.
  5. Reviewer reviews the code.
    • If reviewer is not satisfied, go back to step 2.
    • If reviewer is satisfied:
      1. Reviewer closes the issue1000 branch.
      2. Reviewer merges the issue1000 branch into the default branch.
      3. Reviewer pushes the issue1000 branch and its merge into the master repository.

Commit messages

The first line of the commit message should consist of a self-contained summary and be no longer than 67 characters.

All other lines should be below 80 characters.

Python code

We follow PEP 8.

C++ code

This is not meant to be a complete description of our coding conventions. When in doubt, follow the example of the existing code.

To keep the size of this file reasonable, the following parts have been broken out to subpages:

General recommendations

We generally follow the recommendations in the book C++ Coding Standards: 101 Rules, Guidelines, and Best Practices by Herb Sutter and Andrei Alexandrescu. In the tracker or elsewhere, a mark of the form [SA x] is a reference to a rule in that book. For example, [SA 9] refers to Sutter and Alexandrescu's rule 9: "Don’t pessimize prematurely".


Header file guards

Macro names for header file guards follow this algorithm:

Example: learning/state_space_sample.h becomes LEARNING_STATE_SPACE_SAMPLE_H.

Guard blocks should look like this:

   3 // ...
   4 #endif

That's all. In particular, don't add comments to the preprocessor directives and don't add further underscores.

Function signatures