This is a "work in progress" coding style philosophy document. It doesn't define the style we should go for, rather what we should be thinking about when defining the style rules of a project.
I go with the idea that a team is made up of juniors, intermediates and seniors, and we should make it easy for all of them to be able to contribute to the project.
- Readability: if takes another developer 30 seconds as opposed to 5 seconds to read the code, depending on style then maybe it needs to be clearer
- Maintainability: our code needs to be clear, such that a person fixing a bug doesn't create a new one, because the original code was being 'too smart' or didn't indicate the assumption being made
- Code for everyone: we aren't programming for mathematicians or physicists. While we can make code that would look great as an equation, we should remember why we skipped a heavy maths oriented field. Good naming helps in both readability and maintainability
- Optimisation is nice, but not too soon: while there are common patterns and approaches for making something run well, we shouldn't be spending hours trying to do premature optimisation. Business requirements change and sometimes the real optimisation can be assigned to another ticket, to be done when it makes sense
- Assumptions: if you are going to do something novel or smart, make sure to test it somewhere and try to break it. Not everything we know is right and not everything new is wrong.
- Requirements aren't always clear: make sure the requirements are understood and double check with the person who opened the ticket, whether through the ticket or reaching out to them directly. Requirements will sometimes change following the creation of a ticket or are open to multiple interpretations.