Linting code on CI is a waste of resources. Your time is better spent solving real problems.

But you should lint your code. It helps set a minimum standard.

CI spinup

Spinning up CI instances is heavy and expensive. They run noticably slower than your local machine.

Think of all the steps before linting: tooling, auth and, cloning. You will pay for those resources while your engineer has an idle machine ready to work.

Pre-commit

You should automate the process with a pre-commit hook.

Remove further friction

You can use git’s core.hooksPath to point at your hook scripts. Unfortunately, it won’t be set for fresh clones.

You can make sure it’s set as part of your regular setup process.

Tightening the loop

Only saving on pre-commit means you might miss tasks until you’re done. This can feel like harder work. Running on save will shorten the feedback to fix.

One for all

It’s better to strive for one command that covers all languages. Having one global lint task saves remembering to call it for all language types.

What to lint

Strive to lint as much as possible.

Yes: every single warning. Each one is telling you that something is not quite right.

Better to catch ambiguity early in the process.

All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting. All code must compile with these settings without any warnings. All code must be checked daily with at least one, but preferably more than one, state-of-the-art static source code analyzer and should pass the analyses with zero warnings.¹

TigerBeetle reaches the same conclusion under its “zero technical debt” policy:

Appreciate, from day one, all compiler warnings at the compiler’s strictest setting.²

Not bikeshedding

If your preferred style can’t match standard linting rules you will always fight the tool. And, if you can’t write a rule for it, you should accept the best available option. Agreeing and enforcing lint rules must happen early in a project.