Code conventions

The repository contains a .clang-format file at its root. Use it to automatically format C++ code before committing changes.

Quick example

// Declare all namespaces inline.
namespace VTX::Example
{
    class MyClass
    {          
        public:
            MyClass();
            ~MyClass();

            inline uint getMyUint() const { return _myUint; }
            // Parameters starting with "p_".
            inline void setMyUint( const uint p_parameter ) { _myUint = p_parameter; }

        protected:
            void _myProtectedMethod();

        private:
            // Members before methods, const in uppercase.
            const float _MY_CONST = 0.f;
            uint _myUint = 0;

            void _myPrivateMethod();
    };
}

Best practices

Namespaces and header guards

The namespace should follow the file hierarchy (the class VTX::Util::Foo::Bar from the Util packkage will be in the file lib/util/include/util/foo/bar.hpp).

Header guards should follow the same naming convention (VTX_UTIL_FOO_BAR in this example). If namespaces are very long, you can use statements locally if needed.

Code separation

Maximally separate definitions and implementations. Only "inline" and template functions should be implemented directly in the .hpp file.

For utility functions, avoid using a class; instead, declare the functions directly in the namespace (same rule applies: declare in the .hpp and implement in the .cpp).

In the .cpp file, maintain the same order of implementations as in the header for quicker navigation.

Scope

Always use the most restrictive scope.

Do not use 'using namespace' outside of a function.

Parameters

Name the parameter in the header only when its purpose is not obvious from the function's context.

Parameters are always prefixed with "p_".

Use of "const"

Use const as much as possible (for variables, parameters, function return values, pointers, and "class const" (functions that do not modify class members)).

Smart pointers

Avoid using new; prefer smart pointers instead. However, traditional pointers can still be used if the memory is not owned by the current scope.

Use of "auto"

Use auto only when the type is clear without needing to look at the function's definition. It is especially recommended for iterators, which can quickly become unreadable and error-prone.

Forward declaration

Use forward declaration as much as possible to avoid circular inclusions and reduce compilation times.

Versioning

Create a separate branch named dev-xxx for each developer, where xxx is the developer's initials (e.g., James Patagueule = dev-jpe). The dev branch should always be in a compilable state. The master branch is updated only with each release, accompanied by the appropriate tag.

Version number = Major.Minor.Patch