Code style

Software documentation

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.

Code style

For C++, we generally follow the Google C++ Style Guide.

Naming Conventions

Per above, we intend to follow the Google style guide: classes LikeThis, functions and methods LikeThis() (trivial methods like_this()), local variables like_this, and class member variables like_this_. As of writing, this is not enforced, but we intend to enforce it.

Formatting

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).

How to set up VS Code to the formatting rules

• take this plugin https://marketplace.visualstudio.com/items?itemName=xaver.clang-format
• point it to the clang-format binary at ~/.cache/pre-commit-jlebar

Where is the code?

Should be here, which should also easily lead you to some documentation on the design and architecture.

What should I do next?

Go back to the main wiki and make sure you are familiar with our workflow and collaboration practices.