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").
All .cpp and .h files should be formatted according to the
To automatically fix the formatting, run the command:
If you don't have clang-format version 9.0 or later installed, you can use a docker image or install it as explained below:
You can just use the pre-built docker image:
tools/run-docker.sh tools/fix_style.sh .
You need to have at least clang-format installed.
Install clang-format using brew:
brew install clang-format
sudo apt-get install clang-format-9
You need to add the llvm repository to install clang-format-9:
wget -O - https://apt.llvm.org/llvm-snapshot.gpg.key | apt-key add - apt-add-repository "deb http://apt.llvm.org/xenial/ llvm-toolchain-xenial-9 main" apt-get update apt-get install clang-format-9
The following general guidelines should be used for all code:
C++17 is encouraged to allow developers to use C++17 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.