Every engineer contributing to our projects came with a wealth of experience which informed their preferences around code style and formatting. Each arrived at their preferences through trial, error, success, and failure. Unfortunately each arrived at slightly different conclusions. This was not a sustainable long term approach for a growing team.
The organizational problem with allowing divergent style preferences within a team is that it results in less productivity and a lot of avoidable low-level conflict. People change code unrelated to their work, nitpick pull requests, and expend energy on minutia instead of improving the product.
The technical problem is that this behavior introduces avoidable bugs as code is unnecessarily churned while pull requests become difficult to review as much of the patch has no bearing on the feature being built.
The emotional problem is that people get attached to their own ways and don't want to be forced to follow arbitrary rules which they don't agree with.
In order to support a large number of engineers contributing to a shared set of projects while maintaining consistent style and formatting we had to lean on automation. But before we could lean on automation we had to agree about the problem.
I opened an issue to discuss the problem, laying out the challenge as I saw them. I proposed that we adopt ESLint configured with an extended1 version of AirBnB's ESLint configuration (the extensions would be made to bring it inline with the team's general preferences). The proposal explicitly stated that there was no de facto "rule decider"2, but that anybody could propose modifications. Whether or not to adopt the proposed rule changes would be up to consensus.
There are trade offs. People would have to ensure their code is linted before it can be merged, which is a potential point of frustration. This is an understandable fear: nobody wants errors coming out of nowhere keeping them form getting their work done. The trade off is that what they get out of this compromise is that nobody will nitpick their code – if it passes the linter then style and formatting critique is off the table. A big upside to this is that we can automate the linting work away through editor integration and auto-formatting.
The team agreed. I helped people get their editors configured to automatically surface (and often fix) lint issues. I published @simple/eslint-config
, and integrated it into all of our web applications (no small task).
The outcome has been overwhelmingly positive. Pull Requests no longer get stuck in review for days. There is no back and forth churn of style and formatting as different people work on a file. When linting issues make it into a Pull Request (which is rare, given the widespread use of editor tooling), our CI reports those failures back to the Pull Request before it even gets into peer review.
The Prettier auto-formatting tool has come along in the time since we adopted ESLint. I believe we would have used Prettier for much of what we use ESLint for today. We may yet do that, but our current ESLint setup has addressed all of the productivity issues so there's no pressing need to change tooling yet.