I’d like to add these sections to our code style guide. Are there any objections?
Most of our code does not follow these guidelines yet. Once we have added them to the official style guide, cleanup commits have more justification.
More guidelines can be added in the future. However, these are the once I care about right now. Some of the rules below have many alternatives that are just as good imo. I just picked one, so that we can make our code more consistent.
C++ Namespaces
Namespaces have lower case names.
Blender uses the top-level blender
namespace. Most code should be in nested namespaces like blender::deg
or blender::io::alembic
. The exception are common data structures in the blenlib
folder, that can exist in the blender
namespace directly (e.g. blender::float3
).
Prefer using nested namespace definition like namespace blender::io::alembic { ... }
over namespace blender { namespace io { namespace alembic { ... }}}
.
Tests should be in the same namespace as the code they are testing.
C++ Containers
Prefer using our own containers over their corresponding alternatives in the standard library. Common containers are blender::Vector
, blender::Set
and blender::Map
.
Prefer using blender::Span<T>
as function parameter over const blender::Vector<T> &
.
Class Member Names
Non-public data members of a class should have an underscore as suffix. Public data members should not have this suffix.
Class Layout
Classes should be structured as follows. Parts that are not needed by a specific class should just be skipped.
class X {
/* using declarations */
/* static data members */
/* non-static data members */
public:
/* default constructor */
/* other constructors */
/* copy constructor */
/* move constructor */
/* destructor */
/* copy assignment operator */
/* move assignment operator */
/* other operator overloads */
/* all public static methods */
/* all public non-static methods */
protected:
/* all protected static methods */
/* all protected non-static methods */
private:
/* all private static methods */
/* all private non-static methods */
};
Variable Scope
Try to keep the scope of variables as small as possible.
/* Don't: */
int a, b;
a = ...;
...
b = ...;
/* Do: */
int a = ...;
...
int b = ...;
Const
Use const
whenever possible. Try to write your code so that const
can be used, i.e. prefer declaring new variables instead of mutating existing ones.