Intro
In short this document’s goal is to help us BE CONSISTENT.
The point of having style guidelines is to have a common vocabulary of coding so people can concentrate on what you’re saying rather than on how you’re saying it. We present global style rules here so people know the vocabulary, but local style is also important. If code you add to a file looks drastically different from the existing code around it, it throws readers out of their rhythm when they go to read it. Avoid this.
Principals
It is important to note the development philosophies and tid-bits that drive the quality of code we write. Below we detail a few of the guiding principles we use to ensure our code quality is consistent and uniform across all our products.
On the topic of who we are writing code for:
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
— Kent Beck, Refactoring: Improving the Design of Existing Code
On the topic of writing replaceable code:
Don’t make software “maintainable” or “extensible”; make it replaceable. Instead of wasting time trying to predict a future that will never happen, design software parts to be easily replaceable…
Andy’s Law of Design: If you can’t rip every piece out easily, then the design sucks.
— Andy Hunt, The Four Keys to Rapid Response Software Development
Although the name of the talk sounds a bit like clickbait, Kevlin Henney’s - Seven Ineffective Coding Habits of Many Programmers is a tremendous light-hearted talk about practical and readability-oriented code structure. I highly recommend that you give a quick listen to this talk to hear a typically uncommon perspective on the overall design of code and how developers interact with it. I’m hoping it will inspire us to be a bit more considerate to the developers who come after us.