|
Size: 2006
Comment:
|
Size: 878
Comment:
|
| 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. |
* '''Mailing lists:''' Core developers, please subscribe to both the public and the internal mailing lists mentioned on the HomePage. * '''Admin interface to the internal mailing list:''' http://lists.informatik.uni-freiburg.de/cgi-bin/mailman/admin/downward-dev * '''Python code:''' We follow [[http://www.python.org/dev/peps/pep-0008/|PEP 8]]. |
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
Mailing lists: Core developers, please subscribe to both the public and the internal mailing lists mentioned on the HomePage.
Admin interface to the internal mailing list: http://lists.informatik.uni-freiburg.de/cgi-bin/mailman/admin/downward-dev
Python code: We follow PEP 8.