Cpplint and Clang-format do not automatically check for all our coding rules. These rules must be checked manually in the code reviews.

The full coding guidelines can be found here Guidelines, but here is a list of some common rules that should be checked for in the code review:

• Avoid using forward declarations where possible.
• Avoid defining macros, especially in headers; prefer inline functions, enums, and const variables (Appart from logging).
• The names of variables (including function parameters) and data members are mixedCase / lowerCamelCase with no underscores.
• Data members of classes, both static and non-static, are named like ordinary nonmember variables, but with m_ prefixed.
• Variables declared constexpr or const, and whose value is fixed for the duration of the program, are named with a leading "k" followed by mixed case.
• Numerators (for both scoped and unscoped enums) should be named like macros.
• A class's public API must make clear whether the class is copyable, move-only, or neither copyable nor movable.
• Use a struct only for passive objects that carry data; everything else is a class.
• When using inheritance, make it public.
• Make classes' data members private, unless they are constants.
• Use the prefix form (++i) of the increment and decrement operators unless you need postfix semantics.
• In APIs, use const whenever it makes sense. constexpr is a better choice for some uses of const.
• Use constexpr to define true constants or to ensure constant initialization.
• Mocks should be StrictMocks in the unittests.