This document describes DALI Coding Style Guide.
DALI's C++ code follows Google C++ Style Guide with the exceptions detailed below.
DALI's Python code uses Black for formatting, with the configuration
specified in the pyproject.toml
file, and is checked with flake8
linter according to the .flake8
configuration file.
The code should always pass the current make lint
check, where C++ code and Python formatting
are verified.
Google C++ Style Guide is the default style guide. In places where it limits use of common C++ idioms or language features it is discouraged.
DALI uses C++17 standard as this is the most recent version supported with CUDA versions used in the project.
We use a line length limit equal to 100.
Parameters can be passed as non-const lvalue reference. Google rule
prohibits semantically valid restriction of not passing null pointer
and introduces ugly code like foo(&bar)
or (*buf)[i]
.
We use GTest for most of testing code in DALI. Names of TestSuites should start with a capital letter and end with Test
.
Additionally, both suite and case name mustn't contain underscores (_
).
For details on the latter, cf. GTest FAQ.
Examples:
TEST(MatTest, IdentityMatrix) {} // OK
TEST_F(PregnancyTest, AlwaysPositive) {} // OK
TYPED_TEST(CannyOperatorTest, EmptyImage) {} // OK
TYPED_TEST_SUITE(Skittles, InTheSky); // Wrong! Should be "SkittlesTest"
INSTANTIATE_TYPED_TEST_SUITE_P(Integral, HelloTest, IntegralTypes); // OK. "Integral" is a prefix for type-parameterized test suite
DALI Kernels follow order of Outputs, Inputs, Arguments - where Output and Inputs are expected to be views to Tensors (TensorLists) and Arguments are other inputs.
The same order should be maintained for Kernel template arguments. See the example kernel implementation for details.
The order of the arguments is following memcpy semantics.
DALI uses Doxygen for C++ code documentation with Javadoc-styled comments:
/**
* ... text ...
*/
When the style is left unspecified please follow the one used most in the current codebase. If there is no precedence in the codebase, we are open to discussion, but we hold the final word to avoid endless discussion in that matter.