2006
Comment:
|
814
|
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: | * [[/Mercurial]]: our Mercurial workflow and Mercurial tips and tricks * [[/CodingConventions]]: coding conventions for C++ code * [[/Whitespace]]: how to indent, where to break lines, where to put spaces etc. in C++ code * [[/Uncrustify]]: using the {{{uncrustify}}} source code pretty printer, including integration with Mercurial * [[/CodeReview]]: how to use the Rietveld code review tool with our codebase |
Line 10: | Line 13: |
* [[/Formatting]]: line length, how to break lines, where to put spaces, etc. | == Other bits and pieces == |
Line 12: | Line 15: |
== 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:
/Mercurial: our Mercurial workflow and Mercurial tips and tricks
/CodingConventions: coding conventions for C++ code
/Whitespace: how to indent, where to break lines, where to put spaces etc. in C++ code
/Uncrustify: using the uncrustify source code pretty printer, including integration with Mercurial
/CodeReview: how to use the Rietveld code review tool with our codebase
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.