Quite often when I join a new project, or coach a new development team, I’m surprised by the lack of simple, and to me, obvious tools.

Static analysis tools and linters exist for practically every language out there. Yet so many teams don’t use them. WHY?

Even if you have to pay for the tools, by way of a subscription to a tool like SonarQube, the tool pays for itself very quickly.

Maybe they’re seen as style checkers only? Sure, they can enforce a standard style (and they should, if only to keep developers from bike shedding about tabs vs. spaces and other trivia). But far more important: Such tools often detect real, actual bugs!

Consider this common linter failure in a Go project I’ve recently been helping with:

log.go:203:7: Error return value is not checked (errcheck)
        y := x.(Logger)
             ^

This type assertion has the potential to fail, which would lead to a panic (crash) of the program. Yet this type of lazy type assertions exist everywhere in this code base.

So here’s the point: If you’re working on a project that doesn’t already use a static analysis tool to detect obvious bugs, please start using one today! Start by making it detect only newly added problems, otherwise you’ll likely be overwhelmed by the number of failures, and never fix any of them. Over time, you can begin to clean up the old failures. But first things first: Stop the bleeding!