Wikipedia defines linting software as:

a static code analysis tool used to flag programming errors, bugs, stylistic errors and suspicious constructs.

Linters play an important role to detect common mistakes fast. I often find that running them first in the build pipelines happens already too late, reducing their usefulness.

When to lint to maximize their value?

Software change processes commonly involve the following steps before triggering a pipeline for automated tests:

• change some code
• save the file
• run local tests
• commit changes to version control
• push the changes to the main repository

When linters find a problem during the pipeline steps, it leads to considerable delays: I already done the work, I have to get back to context, apply a fix, save the changes, run local tests, make new commits, and start the pipeline again.

Let’s find a way to do it earlier then.

How about before pushing changes? Or before making commits? As part of the local tests? Upon saving files? We can do even better!

I prefer to configure my editor to run linters asynchronously as I type, and show the results in its UI. That way I get instant feedback about my work. At my fingertips. In most cases even before saving the file I work with.

For example I use Vim with the Asynchronous Lint Engine plugin. Which supports many languages and their linting tools.

Having such frictionless and immediate feedback about what I type helps tremendously.

I recommend to lint as early and as often as possible.

Shift left.