common sense > following rules” especially when following rules takes a lot more time. My approach has never included the need for a style guide.
So what changed? We’re adding a few people to our team. The current approach is something that my brains like, but that doesn’t mean other brains do too. My job is to ensure that all of us can make changes to our development process and make it better. If that change is a style guide, we go with that.
We’ve had a bit of discussion, and there are a couple of reasons why we think adopting a style guide will help us:
- Your brains don’t have to switch between reading separate variations of style. And this saves brain cycles.
- Someone who’s new on the project doesn’t have to worry about how to write code. It’s much better when you can just jump in, be productive and ask questions about architecture and design decisions instead of focusing on spaces and comma’s. And this saves brain cycles.
- Pull Request reviews will focus on the high level, instead of comma’s and spaces. This is because we’ll be using HoundCI for reviewing code style in our Pull Requests, so we don’t have to do that ourselves. And this saves brain cycles.
After a bit of discussion, we picked Thoughtbot’s style guide, mainly because it’s the default in HoundCI. We also looked at bbatsov/ruby-style-guide. We agreed that it didn’t matter which style guide we would pick so long as we stuck with it. We did have some discussion about the preference of using double quotes over single quotes everywhere. We also dropped the max 80 characters line limit.
I am glad about our choice. Especially since we only had a (very!) short discussion on Campfire about it, and everyone agreed with the final decision. There will always be personal preferences and discussion on changing our code style might arise from time to time. I think that that’s perfectly fine and in moments like those I’ll try to remember that having common sense is always better than following rules.