Difference between revisions of "Phobos Quality"
(→Documentation) |
(→Documentation) |
||
Line 5: | Line 5: | ||
== Documentation == | == Documentation == | ||
− | * Uses complete | + | * Uses complete English sentences with correct syntax, grammar, and punctuation. |
* 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. |
Revision as of 15:28, 16 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.