This document describes DALI Coding Style Guide. Rules specified here take precedence over Google C++ Style Guide which should be followed in the remaining cases.
The code should always pass the current make lint check.
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++14 standard as this is the most recent version supported with CUDA.
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.