Linting is the best way to establish and stick to code standards, and is an invaluable part of every project. Here’s our playbook.
Why we ❤️ linters
Setting up linters is one of the first steps on any project at Instrument. The earlier a linter is added to a project, the more we get out of it.
First and foremost, linters help the team align on one standard. They also let us as individuals learn more about the language at hand and develop good habits. On a project level, they guarantee quality and consistency. Linters also ease the learning curve for new developers and for clients post-handoff.
When to lint
Most languages can be integrated into code editors via extensions such as this one. In-editor linting provides a short and direct feedback loop, perfect for when we’re actively writing code.
We also like to lint all code on pre-commit. This way, code that fails the linter can’t even be committed unless an exception is specifically made.
Lastly, we lint as part of our CI process. Linting runs alongside our test suite when Pull Requests are opened and guarantees that we merge code that passes all of our standards.
What linter config should I use?
At Instrument, we let the needs of each specific project drive linting decisions. Using a linter in general is more important than using a particular configuration.
That said, we do have some favorite linters and linter configs that we carry from project to project: