Style Guide

General rules

• Don't repeat yourself (DRY): Avoid repeating code wherever possible by using variables to store data and functions for common routines
• Document your code: Methods and classes should be documented using the Doxygen syntax
• Minimise comments: Good code is self-explanatory and shouldn't need many comments. Try using more descriptive names for variables and functions to keep the code easy to follow for other contributors
• Avoid unnecessary includes: Only include the headers that you need to write your code

Formatting

• Write in English: All code and comments should be written in English
• Use spaces instead of tabs: Tabs should be set to 4 spaces (use Insert Spaces in Visual Studio)
• Functions are actions: Function names should begin with a verb (e.g. transformX())
• Use descriptive names: Names should be precise rather than short (e.g. carLength vs. x)
• Use proper capitalisation:
  • Variables and functions use camel case (e.g. gainFactor or applyGain())
  • Classes start with a capital letter (e.g. AudioPlugin)
• Always use curly brackets({}): Always include curly brackets in a loop, even if it's only one line long
• Place curly brackets ({}) on a new line: Curly brackets should go on the line after a function or loop declaration

Version control

• Describe your commits: Tell other contributors what your commit changed in the commit message
• Don't push without adding unit tests: Make sure to write any unit tests necessary to cover new code before pushing your commits to master
• Don't push if it doesn't compile: Make sure the project builds correctly and all unit tests pass before pushing any commits to the master branch