Should we enforce code style in our large codebase?
- by eighttrackmind
By "code style" I mean 2 things:
Style, eg.
// bad
if(foo){ ... }
// good
if (foo) { ... }
Conventions and idiomaticity, where two ways of writing the same thing are functionally equivalent, but one is more idiomatic. eg.
// bad
if (fooLib.equals(a, b)) { ... }
// good
if (a == b) { ... }
I think it makes sense to use an auto-formatter to enforce #1 automatically. So my question is specifically about #2. I like to break things down into pros and cons, here's what I've come up with so far:
Pros:
Used by many large codebases (eg. Google, jQuery)
Helps make it a bit easier to work on new areas of the codebase
Helps make code more portable (this is not necessarily true)
Code style is automatic once you get used to it
Makes it easier to fast-decline pull requests
Cons:
Takes engineers’ and code reviewers’ time away from more important things (like developing features)
Code should ideally be rewritten every 2-3 years anyway, so it’s more important to focus on getting the architecture right, and achieving high test coverage
Adds strain to code reviews (eg. “don’t do it this way, I like this other way better”)
Even if I’ve been using a code style for a while, I still sometime have to pause and think about how to write a line better
Having an enforced, uniform code style makes it hard to experiment with potentially better styles
Maintaining a style guide takes a lot of incremental effort
Engineers rarely read through the style guide. More often, it's cited in code reviews
And as a secondary question: we also have many smaller repositories - should the same code style be enforced there?
