The following guidelines have been written in hopes of making the plugin more maintainable. They represent what we consider to be good programming practices, and are not necessarily definitive.
Please work in a fork of the repository!
All changes should be made in a branch called feature:# or fix:# (with # being the issue your changes are correlated to).
Once you have tested your change, please make a pull request here.
Comments are great, however, they can generally be replaced with descriptive variable/method/class naming.
Please use comments to describe why you are using something, but let the code describe what you are doing.
Method names should be verbs, class names should be nouns, and Boolean variables should be yes/no statements '(i.e. isRed)'.
We strive for modularity, with every method correlated to a clear function.
Please try to keep your methods under 20 lines, with less than 4 indents.
Check the length of the module you are writing; if it is getting too long, please split it into different functions.
Restricting dataflow makes the code much more maintainable.
Please plan before you code, and consider what methods fit into each class.
Getters and setters are usually a sign that too much data is being transmitted between classes.
Refactors lead to cleaner code, which makes maintenance easier for everyone involved.
They are often less scary than they seem and are almost always worthwhile.
When methods are modularised, they become simpler to understand and debug.
Please divide your code into methods for calculations and methods for side-effects.
Mashing your head against a wall to find a solution generally results in poor implementations.
If you hit a block, please look around for an answer; it will help everyone in the long term.