A linter?

A linter is a piece of software that you can use to analyze the source code you’re writing in order to find potential problems in it, like, for example, syntax errors.

As a Ruby developer, the most basic linter you can use is to go to your terminal and run ruby -wc file_name.rb. It will show warnings and syntax errors in the file. But, as we will see later, things can get (way) more complex.

Enter Atom

This post is written with Github’s Atom editor, as it is what I use day to day and where I have been running my ‘experiments’. I’m pretty sure the tools mentioned here can be found for other editors, and the conclusions apply regardless which editor (and languages!) you use.

Installing and configuring linters

Using linters in Atom is as easy as installing the linter package and then checking the list of packages by AtomLinter and installing and configuring a few. Some of them will require you to install additional gems, so check the docs. Also, most times, you’ll need to specify the route to an executable installed by a gem, either on your config file, or on the package configuration page in Atom.

So far I’m using the following linters to analyze and report errors on my editor for the code languages I use the most:

• linter-ruby
• linter-erb
• linter-haml
• linter-jscs
• linter-coffeescript
• linter-scss-lint
• linter-shellcheck
• linter-docker

Working with linters

This one is easy, you just start writing code and you’ll get the notifications on the status bar of Atom. If you click on them you’ll get a panel with the problems and warnings, explanations and links to the offending code.

It’s cool to have your editor point out you’ve missed a ‘;’ on a .js file, tell you that your haml indentation is wrong, or point out that your CSS rules should be sorted alphabetically (I didn’t know this was a common good practice and it blew my mind). Slowly, you’ll have assimilated some new rules you didn’t pay much attention before.

On the downside, Atom will take a bit more to load up, and the process of saving your files will get a bit slower, as it is saving the file, running the linter and returning back the results. It’s noticeable. Also the default configuration tries to lint your files as you type, but you can have a better performance if you set it to only do it when you save.

Taking things (a bit too?) far

The real fun starts when you get to use linter-reek and/or linter-rubocop. These two will respectively reek (a tool to identify code smells and anti-patterns in your code) and Rubocop (a tool to help you commit to a code style guide) against your code, pointing out violations of coding conventions, code styling conventions and anti-patterns.

So I set them up, open one of my controllers, and… oh, boy, does my code suck… 75 warnings. Fortunately, most of them are about my lines being too long (80 characters per line is still the reccommendation, even in 2016!), or not having proper comments on top of my class declaration… well. Check the gems pages to know more about what they check against, but it varies from checking the spacing between your curly brackets, the naming of your variables, length of your methods, and so on…

Conclusion: is all this really useful?

I’d say yes, especially for starting developers, or those who want to keep consistency in their code, or follow an already given and community curated code style guide. It can be useful for companies to establish a common code style guide through configuration of, for example, Rubocop. I guess the ideal situation would be to reach a common config inside a team, and start new projects using it, so we all know where we’re at.

For legacy projects, it’s just another story. You can try to keep to the common practices and style guide, but also you need to keep consistency with the given codebase, so code looks uniform (and still readable), so there’s a dilemma. Also, you’ll need to force yourself to ignore warnings and errors, as you need to have a feature finished, and can’t really dedicate time to satisfy some nitpicky criteria about spaces around your function parameters. You’ll have to assume that in the future, when you have to work over that area of code, you’ll be able to make it right.

In conclusion, I think these tools are worth a shot, especially the most basic ones (linter-ruby just runs ruby -wc, for example), so they are helpful without being annoying, and things like Rubocop or Reek, keep them on the side depending on the kind of project you’re on.

Do you use linters on your editor? If you dont, then why? I’d like to hear some advice or experience in this area, so comments are very welcome!

Picture ‘Maginification’ by The Giant Vermin, used under CC BY-ND 2.0 license.