348Days

348 days since this post was last revised. Specific details have probably changed.

TL;DR limit the use of linters to highlighting errors. Use formatters to fix stylistic preferences

In the past, at http://ecss.ioon this site and in talks, I have waxed lyrical about using linting tools like Stylelint to point out problems in authored code. As a static analysis tool, a linter is able to point out issues that are both stylistic, such as no closing semi-colon on declarations, and also problematic, such as incorrect values for known properties. I employed a linter as a means to solve both types of problems and encouraged their use to facilitate keeping developers on the straight and narrow in terms of their authored code. Uniformity was the ultimate aim!

However, in recent months I have found myself moving increasingly away from using a linter to point out the stylistic issues. Instead, I’m favouring a formatter for this job. A formatter does as you might expect. On file save (or in your build tool prior to code commit) the file is automatically formatted to match a pre-defined convention. This way, authors can write things however they want, as lax as they please when it comes to things like indentation and white space, and the file will be automagically ‘fixed’ on save.

This change has come about principally after adopting prettier for formatting JavaScript. It’s opinionated for sure, meaning there are likely some choices initially you will take issue with, but the time saving is immediately apparent. 

Adopting it has spelt the end of all debate around how arguments and functions should look, what should have white space and what shouldn’t, and on and on ad infinitum. In short, any downsides have been greatly outnumbered by the positive and when I jump into TypeScript, I really miss having prettier to tidy things up as I go.

So, for CSS, I’m now using a formatter for stylistic preference and a linter to point out potential errors.

The upshot being problems that are easy for a tool to fix automatically get fixed and problems that actually require more author consideration are pointed out for the author to deal with.

So far, I’m just playing with formatters in CSS and I’ve been using stylefmt so far. However, I’d really like to see a fix whereby only rules in the .stylelintrc are used. If that is an issue for you too you can track the issue here: https://github.com/morishitter/stylefmt/issues/86.

Next I’ll be looking perfectionist by the irrepressible Ben Briggs.

It’s early days for out and out CSS formatters but there are plenty of smart folks (and me) talking about the next one here: https://github.com/stylelint/stylelint/issues/2532

Ben Frain Developer, Author: 'Enduring CSS', 'Responsive Web Design with HTML5 & CSS3'.