General approach to coding

[dalonsoa]

Some general rules when developing the tool should be followed to ensure the good quality of the code and a satisfactory developer's experience. The linters and code formatters discussed in another issue can only go so far on this.

• Before coding, create Issues · ImperialCollegeLondon/bubble_analyser (github.com) describing what needs to be done. Issues should be small chunks or work, actionable in a short time and that do not involve much coding. If they are longer, they might be better suited for a Milestone or for an umbrella issue (an issue that is made of multiple issues).
• Code contributions should be made via pull requests (PR) and never merged into the main branch until all the automatic checks have passed and someone else has reviewed and approved the changes.
• Ideally, each PR should tackle one issue - and one issue only. If the issue was correctly formulated, the PR will be small, focussed and easy to review.
• In addition to the code that adds or changes functionality, the PR should also add one or more tests (implemented using pytest: helps you write better programs - pytest documentation, which is the framework in place to do that) and appropriate documentation. At the bare minimum, it should include docstrings in any function, class or method implemented that can be automatically picked and rendered by MkDocs when building documentation.