Difference between revisions of "Phobos Quality"
(→Code) |
(→Documentation) |
||
| Line 8: | Line 8: | ||
* Uses precise technical terms. Avoids colloquialisms. | * Uses precise technical terms. Avoids colloquialisms. | ||
* A synopsis at the beginning motivates the module with an example. | * A synopsis at the beginning motivates the module with an example. | ||
| − | * All members are explained with examples which should also be unit tests. | + | * All members are explained with examples, which should also be unit tests. |
* Honestly describe limitations and dangers. | * Honestly describe limitations and dangers. | ||
Revision as of 18:03, 15 January 2014
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.
