Codestyle

C++ programming guidelines

To allow for a cleaner codebase, contributions should follow a set of coding rules. Those rules must only apply to contributed code, they must never be used to refactor whole files without any other goal, since that would make it harder to use the history to find the reasons of a change.

The rules should aim toward making the code easier to change, even for someone not yet actively contributing.

Rules should be updated in time, depending on the needs and opinions of the contributors. The ruleset must be small enough to keep in mind while actually writing code and ideally complete enough to allow automated checking. The tool used for checking them should however never lead to writing rules: people should not adapt themselves to tools, it's tools that must be adapted to people. If your tool have a problem, modify it, or throw it.

guide lines "extracted" from current code

The current code have some (inconsistent) rules, but some generalities can be seen:

• indentation is made with 4 spaces;
• curly brackets ( '{' and '}' ) are alone on their lines;

new contributions guidelines

• C++14 can be used. No C++17 yet;
• avoid using macro as much as possible. If you need a macro, using an actual function is usually better;
• all blocs (even of 1 line) must be surrounded with curly braces: no 'for(;foo;)bar;';
• only 1 instruction per line. Some exceptions might make sense though;
• long lines should be split, and proper alignment set (char limit is to be defined, but keep in mind not everyone have big screens nor good eyes, and being able to view 2 files at a time per screen is a nice feature);
• symbols (variables, functions, methods, macro, defines) must not be prefixed with underscore ('_') since the standard reserves that in some cases. In some cases, it would be legal, but let's avoid the useless risk;
• use snake_case naming, no camelCase;
• do not throw exceptions, manage errors by returning either:
  • a null or a valid pointer;
  • an object than can be explicitly checked for (in)validity (the problem of constructors with parameters can be worked around with named constructors);
  • a std::optional object;
  • a specific enumeration where 0 means no error;
  • a boolean where false means no error;
• avoid using internal containers, or patch them to add them STL-like API;
• 'new' and 'delete' are forbiden. Use a container for dynamic allocation. If you need class hierarchy in a container, Use 'std::unique_ptr' and 'std::make_unique' instead of raw pointers;
• no 'std::shared_ptr' as they makes it harder to know which object is responsible for creation and deletion;
• avoid using raw pointers as much as possible (must only be used for some associations;