-
-
Notifications
You must be signed in to change notification settings - Fork 37
Code style
Documentation on how to build and test the code is in the same directories as the code. Try to keep documentation close to the code that it explains. If you make changes that affect assumptions about hardware or build toolchain, make sure the relevant documentation is updated.
If you are implementing anything related to specific hardware, reference relevant datasheets or specification documents. Do so gratuitously, especially if there are firmware constants or other "magic numbers", so that they are easy to track down and double-check manually if in doubt.
For C++, we generally follow the Google C++ Style Guide.
Per above, we intend to follow the Google style guide. There may be slight deviations from the guide based on how our static checkers can be configured:
- classes, enums, constants and namespaces
LikeThis
- functions and methods
like_this()
- function parameters, local variables and public member variables
like_this
- private and protected member variables
like_this_
As of writing, this is not enforced, thoughclang-tidy
static checks will provide warnings.
All files should have an Apache2 license header.
Follow Doxygen guide for documenting code. For example, all TODO's should look like
\todo implement important error check
We autoformat both C++ and Python code: c++ using clang-format
, Python using black
.
Make sure you install our pre-commit hooks: they will reformat your code on commit, and error out if any changes were made (in that case, simply amend your commit with the formatting changes).
- take this plugin https://marketplace.visualstudio.com/items?itemName=xaver.clang-format
- point it to the clang-format binary at
~/.cache/pre-commit-jlebar
Should be here, which should also easily lead you to some documentation on the design and architecture.
Go back to the main wiki and make sure you are familiar with our workflow and collaboration practices.