To lint or not to lint

In general it is always a good idea to run static checkers through the code. It catches some obvious mistakes and helps maintain a readable code base — at least most of the time. But some checkers are quite aggressive, or some rules may be too outdated or simply don’t match the preferred coding style of the programmer.

Nevertheless, here are my two cents on linters and other static checkers:

A short snippet of in-line code is fine, but anything that resides in its own .js file deserves a lint. If you have to write JavaScript (*cough*coffee*cough*script*cough*), you have to lint it. To keep the bad parts out.

  • Go: always run gofmt and go vet!

  • Python: well, that’s a tricky one…

  • pyflakes is a must, it will catch not just errors, but things like unused imports and locals, re-defined variables and such.
  • pep8 should be run too, but you may want to disable some checks if you’re like me (I don’t quite agree with the visual/hanging indent rules and sometimes I don’t want to try and fit in <79 char lines)
  • autopep8 can be useful sometimes, though it is best to not let things out of hand so much to need it in the first place
  • flake8 is a handy combination of pyflakes and pep8
  • pylint is useful but very strict; it will force you to split functions but won’t let you use too many function arguments; but at least it will rate your code on a 1-10 scale.

For less-strict checkers like gofmt and pyflakes, it is a good idea to install them as commit hooks. There are also vim plug-ins for most of these, so you see the problems right as you edit the file (or when saving). The advantage of of the static regex-based checkers is that they are fast enough to run on every change you make to the buffer.

Update

For Go there is also golint, which can be useful, for example it detects for x, _ := range and reports to drop the _; However, it mostly complains about missing comments :) And there’s also this.