How to enforce coding styles across a team

Yesterday, I wrote about how your code base should look like one person wrote it, even when you have a team.

A big part of that is having a code style guide that documents team norms around authoring code. But in larger code bases, manually reviewing and enforcing that can become a big time suck.

That’s where tooling can be useful! My favorite tool for this is ESLint.

ESLint’s primary role is as a code linter to catch bugs. I typically prefer the simplicity of JSHint for my own personal projects, but in a team setting, I like the breadth of configurations ESLint offers.

You can configure it to, for example, throw errors when someone uses var instead of let or const. A lot of style configurations that used to be in core got moved to the ESLint Stylistic plugin, like requiring spaces before parentheses when writing functions.

What’s also great about ESLint is that you can install a plugin for your code editor and it will lint your code in real time while you type, letting you fix things as you work. You can run it as part of CLI build process, and even integrate it into a continuous deployment workflow to reject git commits that have errors.

I occasionally have folks recommend Prettier to me. Prettier automatically reformats code, and I think that’s a worse choice for a few reasons…

1. Formatting compiled code is of almost no value. That’s the code that’s designed to be ready by robots, not humans. Having source code with a consistent format is the important part.
2. It can format the source code instead, but then you’re literally wiping out what you wrote and replacing it with something else. You’ve gotta really trust your tool, and that’s jarring AF.
3. It can alternatively just provide errors. That’s more useful, IMO, but unlike ESLint, it just tells you the affect file, not what specifically you need to fix.

For all of those reasons, I’d much rather drop ESLint into a project.