Difference between revisions of "Phobos Quality"
(→Documentation) |
|||
| Line 20: | Line 20: | ||
* Observe usual good engineering practices (clarity, one entity/one responsibility, avoid code duplication etc). | * Observe usual good engineering practices (clarity, one entity/one responsibility, avoid code duplication etc). | ||
* Maximal <tt>pure</tt>, <tt>@safe</tt>, and <tt>nothrow</tt> unless deduction is in effect. | * Maximal <tt>pure</tt>, <tt>@safe</tt>, and <tt>nothrow</tt> unless deduction is in effect. | ||
| + | |||
| + | [[Category: Contribution Guidelines]] | ||
Revision as of 20:01, 8 September 2015
This page documents the level of quality that Phobos strives for. Especially new modules should be judged according to these guidelines.
Documentation
- Uses complete English sentences with correct syntax, grammar, and punctuation.
- Uses precise technical terms. Avoids colloquialisms.
- A synopsis at the beginning motivates the module with an example.
- All members are explained with examples, which should also be unit tests.
- Honestly describe limitations and dangers.
Code
- Follows the style guide and being consistent in general.
- Appropriate unittesting, coverage should be at or near 100%.
- Avoid unnecessarily importing other Phobos modules.
- Try to not require a garbage collector (this is not a must).
- Module boundary is sensible, which means no temptation to split it into multiple modules nor to merge it into another module.
- Observe usual good engineering practices (clarity, one entity/one responsibility, avoid code duplication etc).
- Maximal pure, @safe, and nothrow unless deduction is in effect.
