2006
Comment:
|
694
|
Deletions are marked like this. | Additions are marked like this. |
Line 3: | Line 3: |
= Coding conventions = | = Information for developers = |
Line 5: | Line 5: |
This is not meant to be a complete description of our coding conventions. When in doubt, follow the example of the existing code. |
Subpages: |
Line 8: | Line 7: |
To keep the size of this file reasonable, the following parts have been broken out to subpages: | * [[/Workflow]]: our Mercurial workflow * [[/C++Code]]: coding conventions and style guide for C++ code * [[/C++Whitespace]]: how to indent, where to break lines, where to put spaces etc. * [[/Uncrustify]]: using the uncrustify source code pretty printer, including integration with Mercurial |
Line 10: | Line 12: |
* [[/Formatting]]: line length, how to break lines, where to put spaces, etc. | == Other bits and pieces == |
Line 12: | Line 14: |
== General recommendations == We generally follow the recommendations in the book [[http://www.gotw.ca/publications/c++cs.htm|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". == Namespaces == * Every subdirectory should correspond to a namespace. * Avoid nested namespaces or subdirectories of subdirectories. * Namespaces follow the same camel-case naming convention as classes, while directory names follow the naming conventions for methods and variables. For example, file {{{my_subdir/my_class.h}}} would be expected to contain a definition of class {{{MySubdir::MyClass}}}. * Namespaces should have short, single-word names if possible. (The previous example only uses an underscore in the subdirectory name for sake of illustration.) == Header file guards == Macro names for header file guards follow this algorithm: * Take the filename, including subdirectory name if in a subdirectory. * Convert to uppercase. * Replace all "{{{.}}}" and "{{{/}}}" with "{{{_}}}". Example: {{{learning/state_space_sample.h}}} becomes {{{LEARNING_STATE_SPACE_SAMPLE_H}}}. Guard blocks should look like this: {{{#!cplusplus #ifndef LEARNING_STATE_SPACE_SAMPLE_H #define LEARNING_STATE_SPACE_SAMPLE_H // ... #endif }}} That's all. In particular, don't add comments to the preprocessor directives and don't add further underscores. |
* '''Python code:''' We follow [[http://www.python.org/dev/peps/pep-0008/|PEP 8]]. * '''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'''. |
Back to the HomePage.
Information for developers
Subpages:
/Workflow: our Mercurial workflow
/C++Code: coding conventions and style guide for C++ code
/C++Whitespace: how to indent, where to break lines, where to put spaces etc.
/Uncrustify: using the uncrustify source code pretty printer, including integration with Mercurial
Other bits and pieces
Python code: We follow PEP 8.
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.