"Programs must be written for people to read, and only incidentally for machines to execute." ― Hal Abelson
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." ― John Woods
"Refactoring is like cleaning dishes after cooking." — Toby Parkins
The objective of this documentation is to provide a set of commons rules to use on this project with a long term vision.
This documentation SHOULD not be used as a unique response to the question "What is a clean and organized code ?" but MUST be used as the only reference when developing on this repository. Evolutions are made by collegial decisions from the internal team and SHOULD be driven by a gain either in homogeneity, readability or maintainability. If no consensus can be found, the decisions are taken by the lead team with the global context in mind.
Main goals are to:
- Keep the code homogenous, readable and maintainable. All developers SHOULD be able to read the code.
- Give the developers an environment where there is no need to think about how the code is structured.
- Check that your code matches the standards and passes the automated tests, before asking for a review and merging.
- Be concise when writting documentation and comments.
- Always source your statements in your PR to ease review.
- Be polite, always, no exceptions.
- 🇬🇧 Documentation is now mostly in English (feel free to help and correct 😉)
- 🌍 The documentation has been updated to be more open-source community oriented
- 💡 More coding rules have been added
- Add open-source licenses
- Add technical documentation
- Add
CONTRIBUTING.mdfile for contributors - Add correction and precisions to the contributing rules
- Add a CHANGELOG to ease standards evolution spotting
- First architecture proposition