|
Size: 2006
Comment:
|
Size: 1791
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: | * [[/AddingSourceFiles]]: how to add new source files to the planner * [[/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 * [[/Includes]]: using {{{include-what-you-use}}} to find missing/redundant includes and forward declarations * [[/CodeReview]]: how to use Bitbucket code reviews or the Rietveld code review tool with our codebase * [[/GkiGrid]]: how to run experiments on the GKI grid in Freiburg * [[/BuildBot]]: buildbot information * [[/ImplementationDetails]]: more in-depth descriptions on how some classes are implemented * [[/CodeBasesToMerge]]: code from papers we want to merge in the (medium-term) future * [[/ReviewQueue]]: Malte's FIFO list of issues to review * [[/LongTermPlans]]: long-term wishlist of changes with broader scope * [[/ProblemTransformations]]: problem transformations performed by the planner that might trip up users interested in non-classical planning * [[/CmakeTipsAndTricks]]: tips and tricks for CMake * [[/Profiling]]: on using valgrind and friends |
| Line 10: | Line 24: |
| * [[/Formatting]]: line length, how to break lines, where to put spaces, etc. | == Other bits and pieces == |
| Line 12: | Line 26: |
| == 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:''' https://www.maillist.unibas.ch/mailman/options/downward-dev/ * '''Python code:''' We follow [[http://www.python.org/dev/peps/pep-0008/|PEP 8]] and support Python 2.7 and Python >= 3.2. |
Back to the HomePage.
Information for developers
Subpages:
/AddingSourceFiles: how to add new source files to the planner
/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
/Includes: using include-what-you-use to find missing/redundant includes and forward declarations
/CodeReview: how to use Bitbucket code reviews or the Rietveld code review tool with our codebase
/GkiGrid: how to run experiments on the GKI grid in Freiburg
/BuildBot: buildbot information
/ImplementationDetails: more in-depth descriptions on how some classes are implemented
/CodeBasesToMerge: code from papers we want to merge in the (medium-term) future
/ReviewQueue: Malte's FIFO list of issues to review
/LongTermPlans: long-term wishlist of changes with broader scope
/ProblemTransformations: problem transformations performed by the planner that might trip up users interested in non-classical planning
/CmakeTipsAndTricks: tips and tricks for CMake
/Profiling: on using valgrind and friends
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: https://www.maillist.unibas.ch/mailman/options/downward-dev/
Python code: We follow PEP 8 and support Python 2.7 and Python >= 3.2.