Currently conventions.md is mostly empty. It should be filled with current code conventions for those that are already consistent.
Also, some practices are not currently consistent. Here are (probably non-exhaustive) lists
on C++ side:
- template parameters, sometimes suffixed by a
T, sometimes not.
- type aliases exposed by classes, randomly typed as
Foo_t, FooT, foo_type, foo_t or just Foo.
- order of includes.
- name of include guards.
- some public
static constexpr member variable, or non-type template params are sometimes snake_case, sometimes camelCase. There is also a non-uniform usage of dim and dimension.
- function naming is not homogeneous: sometimes snake_case, sometimes camelCase, with no rule to chosse between the top options
on python side:
- function naming: when camelCase should be used is not clearly precised.
- no enforced formatting like.
on cmake/testing side:
- registering level system to classify jobs by computational weight could be improved to stop using raw constants.
For those inconsistent practices, definitive conventions should be established first, so that every new line of code can follow them. Old inconsistent code could be corrected progressively later on.
Currently conventions.md is mostly empty. It should be filled with current code conventions for those that are already consistent.
Also, some practices are not currently consistent. Here are (probably non-exhaustive) lists
on C++ side:
T, sometimes not.Foo_t,FooT,foo_type,foo_tor justFoo.static constexprmember variable, or non-type template params are sometimes snake_case, sometimes camelCase. There is also a non-uniform usage ofdimanddimension.on python side:
on cmake/testing side:
For those inconsistent practices, definitive conventions should be established first, so that every new line of code can follow them. Old inconsistent code could be corrected progressively later on.