Are formatters better than linters?

So, I just watchedMichał Muskała’s talk at CodeBEAMSF, and I have something to say…

As you might know, I’m also working withJuan Bono, Diego Calero ,Facundo Olano, and others on our own formatter for Erlang (just like Daniel Tipping is working on steamroller ). I could write an article on how our formatter differs fromMichał’s but this time I want to focus our attention on a different topic.

Particularly I want to look at the following slide…

Formatters are more than Linters

Are Formatters “Linters on Steroids”?

Michał presents a concept in his talk that is somewhat widespread and I don’t think it’s correct: The idea that if linters can tell you where you need to improve your code, formatters are better because they can just fix it.

Having worked on both Elvis (a linter) and rebar3_format (a formatter), I do believe that they are complementary but independent tools. They do have some intersection, but the really interesting parts are the ones where they don’t intersect with each other. And I believe this happens as well in other languages, for instance with Credo and mix format for Elixir.

There are things that linters can detect, but formatters can’t fix. To name a few Elvis rules like that:

• Nesting Level : The linter can detect that your code is nested too deeply, but what will the formatter do to fix that? It could theoretically move some lines out to a different function but I don’t think that’s something you would expect your formatter to do, right?
• No debug calls : The linter can tell you that you left some io:format ’s in your production code, which is not good. I don’t think the formatter should just remove them . Leaving aside the fact that sometimes it’s not as easy as just removing the calls.
• DRY : My favorite Elvis rule of all time: The linter can identify pieces of code that are repeated. What will the formatter do here? A tool that would actually refactor your code to extract them to a separate function would be amazing but I don’t think the formatter should be that tool.

If only we had a tool to automatically perform all those tasks… MaybeSimonThompson knows one ?

On the other hand, there are things that a formatter can fix and a linter shouldn’t deal with, like:

• Consistent indentation of clauses. The linter can warn you on whether you’re using tabs or spaces for indentation but figuring out if you properly indented all your code using the right number of spaces/tabs is not worth the effort, particularly if you have a tool like a formatter that just fixes that for you .
• Personalization. As I mentioned in my article linked above, I believe that formatters should have room for personalization, so I can read the code in the way I understand it best and you can read the same code in the way that you like it best. We don’t need to fight over comma-first ROK-style, indentation levels, tabs-vs-spaces… As long as we share a format for the code once its pushed, each one of us can work using his/her own style. That’s something that the linter can’t allow since the idea is that the rules enforced by the linter are respected by all of us.

Conclusion

The linter and the formatter are different tools that serve different purposes. The linter will make sure your code is well written and follows the best practices defined by the community or your team. The formatter will make sure that your code is nicely written and easy to understand by any other developer.

A formatter will happily make some linter rules obsolete (which is great!) but it won’t remove the need for it, at all.

In other words…

Don’t stop using a linter when you start using a formatter!