Skip to content

Code style

Martin Shetty edited this page Jun 21, 2022 · 11 revisions

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. 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, though clang-tidy static checks will provide warnings.

License headers

All files should have an Apache2 license header.

Code documentation

Follow Doxygen guide for documenting code. For example, all TODO's should look like

\todo implement important error check

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

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.