C++ Coding Style
This topic contains the SDK C++ formatting and coding guidelines.
These guidelines are not written in stone! Start a discussion if you have suggestions for improvement (the project will consider anything other than "matters of personal taste").
Formatting and White Space
To automatically fix the formatting, run the command:
- Line length should be kept below 100 characters.
- Enables 3-way-merges with 3 columns possible on decent monitors.
- Discourages too many nested ifs.
- Large enough o allow for verbose naming and prevent abbreviations.
The following general guidelines should be used for all code:
C++11 is encouraged to allow developers to use C++11 features and the standard library. Examples:
using namespace stdis discouraged (read why). If needed specific declarations can be used in the source files such as
using std::this_thread::sleep_forto reduce verbosity.
- The usage of namespacing wherever possible is encouraged (e.g.
enum classis to be used over
- Filename extensions should be
.hfor header files and
.cppfor source files (for consistency).
- Variable and method names should err on the side of verbosity instead of being quick to type and read. Abbreviations are only to be used for small scopes and should not be exposed in public APIs.
- All variables that have a physical unit should have the unit in the variable name (e.g.
- Variable and method names should be
snake_caseand class/struct/enum names
CamelCase. Private variables should start with an underscore, e.g.:
- Try to exit functions early instead of nesting ifs (read why).
- We don't use exceptions but use error codes. There are pros and cons for exceptions but given that the public API should be as simple as possible, it makes sense to refrain from exceptions altogether.