Coding Guidelines

Documentation

All classes and their public & protected members should be documented using Doxygen. The Doxygen documentation is automatically compiled when the CMake-option SPNC_BUILD_DOC is enabled.

Code formatting

The project uses a unified code style. A configuration file for the Clion IDE is provided here.

Each new C++ file should bear the following header:

//==============================================================================
// This file is part of the SPNC project under the Apache License v2.0 by the
// Embedded Systems and Applications Group, TU Darmstadt.
// For the full copyright and license information, please view the LICENSE
// file that was distributed with this source code.
// SPDX-License-Identifier: Apache-2.0
//==============================================================================

Each new Python or CMake file should bear the following header:

# ==============================================================================
#  This file is part of the SPNC project under the Apache License v2.0 by the
#  Embedded Systems and Applications Group, TU Darmstadt.
#  For the full copyright and license information, please view the LICENSE
#  file that was distributed with this source code.
#  SPDX-License-Identifier: Apache-2.0
# ==============================================================================

The headers can be configured via the code templates of the CLion IDE or CLion's Copyright templates.

Branching & Review

This project follows the git-flow model. New features should be developed on feature-branches prefixed with feature/, branching from develop.

Before a feature is merged into develop, please setup a pull-request and request a code review of another project member.

Code Quality

Warnings

To improve code quality, the project per default uses -Wall to increase the warning level of the compiler. Before submitting a pull request, make sure that your code compiles without any (avoidable) warnings.

clang-tidy

The project build system integrates clang-tidy and defines a number of checks that are performed. Before submitting a pull request, make sure that your code does not trigger any (avoidable) clang-tidy warnings.

There are two ways of running clang-tidy in the project, both require clang-tidy to be installed (e.g., sudo apt install clang-tidy on Ubuntu):

• Enable -DSPNC_ENABLE_CLANG_TIDY=ON and -DCMAKE_EXPORT_COMPILE_COMMANDS=ON during CMake configure. This will automatically run clang-tidy on the source files as part of the build step. The downside of this is that compile time increases.
• Therefore, you can alternatively only enable -DCMAKE_EXPORT_COMPILE_COMMANDS=ON use the auto-generated wrapper script. During CMake configuration, the build system will create an executable script called wrap-clang-tidy.sh in your build folder. Simply invoke this script to run clang-tidy with the right checks enabled as a standalone command (parallelized via run-clang-tidy).

clang-tidy is also executed as part of the CI process for each PR (and updates of each PR). CI will automatically attach a comment to the PR with clang-tidy warnings, if any occur. To avoid an excessive number of comments in the PR, you should run clang-tidy locally before submitting.