... | @@ -82,6 +82,11 @@ Important rules, and notable differences are summarized here: |
... | @@ -82,6 +82,11 @@ Important rules, and notable differences are summarized here: |
|
- do not use e.g. ```i```, if ```i``` is used in more than a single line of code; rather use ```index```, or ```count``` or whatever is appropriate
|
|
- do not use e.g. ```i```, if ```i``` is used in more than a single line of code; rather use ```index```, or ```count``` or whatever is appropriate
|
|
- Same for ```p```, if it should be ```particle``` etc.
|
|
- Same for ```p```, if it should be ```particle``` etc.
|
|
|
|
|
|
|
|
### Declaration Specifiers
|
|
|
|
- ```const``` should be placed as far right as possible e.g. ```type const& foo``` ```type const* foo``` or ```type* const foo```. Use the ([right-to-left rule](http://cseweb.ucsd.edu/~ricko/rt_lt.rule.html)).
|
|
|
|
- ```constexpr``` follows the same pattern and is placed before the ([declarator](https://en.cppreference.com/w/cpp/language/declarations))
|
|
|
|
|
|
|
|
|
|
### Class Design
|
|
### Class Design
|
|
|
|
|
|
- Classes are designed like this:
|
|
- Classes are designed like this:
|
... | @@ -90,8 +95,8 @@ Important rules, and notable differences are summarized here: |
... | @@ -90,8 +95,8 @@ Important rules, and notable differences are summarized here: |
|
- Everything that should not change should be ```const```.
|
|
- Everything that should not change should be ```const```.
|
|
- A ```const``` argument should be written as ```TypeName const var``` (not ```const TypeName var```)
|
|
- A ```const``` argument should be written as ```TypeName const var``` (not ```const TypeName var```)
|
|
- Access data members using getters and setters
|
|
- Access data members using getters and setters
|
|
- for setters use either by value ```setValue(type value)``` or, if ```type``` is not an integral type by reference ```setValue(const type& value)```
|
|
- for setters use either by value ```setValue(type value)``` or, if ```type``` is not an integral type by reference ```setValue(type const& value)```
|
|
- for getters use by value ```type getValue() const {return value_;}```, or by reference ```type& value() {return value_;}``` respectively ```const type& value() const {return value_;}```. Note, use the from ```value()``` only when it returns a reference to a data member, i.e. for function chaining.
|
|
- for getters use by value ```type getValue() const {return value_;}```, or by reference ```type& value() {return value_;}``` respectively ```type const& value() const {return value_;}```. Note, use the from ```value()``` only when it returns a reference to a data member, i.e. for function chaining.
|
|
- For logical states, use ```bool isTrue() const``` or ```bool hasThis() const```. Avoid ```bool isNotNeeded() const``` since it is just ```!isNeeded()```.
|
|
- For logical states, use ```bool isTrue() const``` or ```bool hasThis() const```. Avoid ```bool isNotNeeded() const``` since it is just ```!isNeeded()```.
|
|
- Data member declarations follow after method declarations.
|
|
- Data member declarations follow after method declarations.
|
|
- Classes need to be documented with doxygen commands.
|
|
- Classes need to be documented with doxygen commands.
|
... | @@ -168,7 +173,7 @@ Important rules, and notable differences are summarized here: |
... | @@ -168,7 +173,7 @@ Important rules, and notable differences are summarized here: |
|
Wine wine_;
|
|
Wine wine_;
|
|
};
|
|
};
|
|
```
|
|
```
|
|
- Reflect about the resources the class is holding and if makes sense to move or copy them.
|
|
- Reflect on the resources the class is holding and if makes sense to move or copy them.
|
|
Implement non-default or long components in the *.inl.
|
|
Implement non-default or long components in the *.inl.
|
|
- Follow the ```rule of zero/five```. This concerns any of the following methods handling an object lifecyle:
|
|
- Follow the ```rule of zero/five```. This concerns any of the following methods handling an object lifecyle:
|
|
|
|
|
... | @@ -186,16 +191,14 @@ Important rules, and notable differences are summarized here: |
... | @@ -186,16 +191,14 @@ Important rules, and notable differences are summarized here: |
|
|
|
|
|
- Each functional group of classes has a unit test ```testThis.cpp```. See [Guidelines for Unit Tests](Guidelines-for-Unit-Tests) for details.
|
|
- Each functional group of classes has a unit test ```testThis.cpp```. See [Guidelines for Unit Tests](Guidelines-for-Unit-Tests) for details.
|
|
- Adhere to C++17 standards. In particular:
|
|
- Adhere to C++17 standards. In particular:
|
|
- Define public, private and protected type aliases and typedefs on the top, inside the class or
|
|
- Define public, private and protected type aliases and typedefs on the top, inside the class or method they are necessary. It should be written in minor letters, suffixed by "_type", like in ``` typedef
|
|
method they are
|
|
|
|
necessary. It should be written in minor letters, suffixed by "_type", like in ``` typedef
|
|
|
|
ClassA someclass_type```.
|
|
ClassA someclass_type```.
|
|
- Template, meta programming:
|
|
- Template, meta programming:
|
|
- Template (meta) parameters are identified by a prefixed "T", like ```template <typename TProperty>```.
|
|
- Template (meta) parameters are identified by a prefixed "T", like ```template <typename TProperty>```.
|
|
This makes it easier in writing code to distinguish classes and types from template (meta) parameters.
|
|
This makes it easier in writing code to distinguish classes and types from template (meta) parameters.
|
|
- For class templates, provide deduction guides, if applicable. Also, add instance makers
|
|
- For class templates, provide deduction guides, if applicable. Also, add instance makers
|
|
as free functions in the concerning namespace, to deploy type deduction and avoid explicit
|
|
as free functions in the concerning namespace, to deploy type deduction and avoid explicit
|
|
template instantiation. Look the example below:
|
|
template instantiation. Look at the example below:
|
|
```
|
|
```
|
|
// prototype example of a class to manage process queue, that should be able to
|
|
// prototype example of a class to manage process queue, that should be able to
|
|
// dispatch processes in parallel o sequentially, according to TParallelPolicy
|
|
// dispatch processes in parallel o sequentially, according to TParallelPolicy
|
... | @@ -309,7 +312,7 @@ warning using the flag ```"FIXME"``` as keyword. |
... | @@ -309,7 +312,7 @@ warning using the flag ```"FIXME"``` as keyword. |
|
/**
|
|
/**
|
|
* Here we have a length comment on the purpose of this function TimeOfIntersection to explain that
|
|
* Here we have a length comment on the purpose of this function TimeOfIntersection to explain that
|
|
* it calculated the "time of intersection" and all the strange symbols and conventions used here.
|
|
* it calculated the "time of intersection" and all the strange symbols and conventions used here.
|
|
* Such a comment only bloats the code, and provides not further information compared to the code above.
|
|
* Such a comment only bloats the code, and provides no further information compared to the code above.
|
|
**/
|
|
**/
|
|
TimeType TimeOfIntersection(Line const& l, Plane const& p) {
|
|
TimeType TimeOfIntersection(Line const& l, Plane const& p) {
|
|
auto const d = p.GetCenter() - l.GetR0();
|
|
auto const d = p.GetCenter() - l.GetR0();
|
... | | ... | |