The following guidance details our minimum level of standards for any work created by the Development team.
This guidance is a combination of our collective experience, industry best practice and deliberate decisions made to foster consistency and ease of maintenance. The old adage goes that "80% of software development is maintenance" - so remember to think about the next developer on any project.
Our industry is young and best practice can be a moveable feast. Be deliberate in your choices and remember that just because you can does not mean you should.
These are living 🍃 documents, and can be contributed to by any member of the team, provided a pull request is made beforehand.
The keywords within these documents are consistent and developers with information that is easy to digest. The following terms are used throughout:
- must - The rule defines an action which must be taken.
- must not - The rule defines an action which must not be taken.
- should - The rule defines actions which should be taken, but only where practical and may be excepted.
- should not The rule defines actions which should not be taken, but only where practical.
- exceptions - Some rules have exceptions which when applicable, usually mean that the rule can be safely ignored.
- optionally - This portion of a rule is optional, but still considered good practice.
- Administration /
- Coding /
- Production /
- Resources /
If you want to contribute, modify or otherwise get involved with the production of these standards: Great! Thank you! Please look at the Contributing file before submitting any requests and feel free to create an issue if you aren’t sure what kind of thing it is you want to add.