SCSS linting matters

TLDR: Lint your SCSS.

Linters have been around for a while now and it's fair to say that if you're writing any sort of code; you probably are using one yourself. If you aren't using one, I'm sure you have a good reason…

When we first started using linters our focus was always JavaScript as this was the majority of the code that we were writing. We had an agreed set of rules that would be taken to each project as a standard and then if they needed to be adapted or added to this was okay. It worked out well and our JavaScript was looking top notch! Everyone was happy with the rules we had set out, though frustrations would definitely be had if you had broken the build from using 'var' instead of 'let' or a double quote instead of a single quote. Definitely not referring to myself here...

Really, I'm not. Let's move on...

When it comes to writing CSS and/or SCSS it's fair to say that things were a little different and sadly not the good kind. We made the decision to move to SCSS a fair few years ago now and don't get me wrong, it has been an awesome change, SCSS is fantastic! But because we didn't have any linting (or an agreed set of rules/standards) for writing CSS, it meant that when we started SCSS, that continued.

CSS or SCSS could end up looking sloppy, rather than it being of important value. It was quickly thrown together with little thought and certainly no concern for how readable it was. I am being particularly harsh here but when we started to take JavaScript very seriously, I took the view that we should do the same with our SCSS.

SCSS is code too!

Looking for a solution, I found https://stylelint.io/, which is a wonderful and easy to use plugin that works for CSS and SCSS. We could easily integrate with gulp which is our preferred choice of tools for builds, minifying, compiling etc. There are a lot of rules to choose from here so we tried out some different configurations to find out what worked best and eventually settled on a set everyone was happy with; which is now used on each project.

What this meant was that when styles were written they looked like this:

.card{
    position:relative
      background: $card-text-color;
    padding: 15px;
    font-size: 18px; color: white;
    padding:20px;

}

This would instantly get picked up by the linter and they would have to be fixed, meaning we get a much nicer result of:

.card {
    position: relative;
    background: $card-bg-color;
    font-size: 18px;
    color: $card-text-color;
    padding: 20px;
}

Which is a lot tidier, neater and easier to read. It's important to clarify what exactly the linter found here and what did the developer have to change; as there are some assumptions. The obvious things are indentation, incorrect spacing, duplicate properties and general formatting. The linter finds all these and the developer fixes, all good. However, in my experience when a linter finds these kinds of things as the developer, you tend to spot other things as well. So in this example it's replacing the variables so they are correct; in this case the background and color are variables.

Sadly the linter isn't smart enough to detect you've used incorrect variables for your CSS properties. But hey, wouldn't that be neat one day?

But why bother?

It's all well and good me talking about this, but why should you actually bother doing it yourself? Well, a lot of the reasons are the same for linting your JavaScript; it shouldn't be different just because it's SCSS. One of the most important reasons for doing this which is essential for all types of programming is readability; all code should be easy to read and understand from a brief scan. SCSS should be the same. You should be able to read over a .card class and quickly understand roughly what it's going to look like based on the SCSS written. If properties aren't indented correctly or repeated or there's incorrect use of variables, then it becomes a lot harder to understand what the styles actually mean.

Step in a SCSS linter…

Introducing a linter for your SCSS can remove these problems by flagging them up early so people can fix them. Then through further usage of the linter, the same mistakes can be avoided because they learn the rules and follow them without even thinking about them. This leads to all members of your development team writing better SCSS at the quality that you have chosen. All because you added a SCSS linter to your project.

Rounding it up

In summary, SCSS linting should be just as important as JavaScript linting because it can impact the way you write your SCSS, improve developers skills and in the end, produce better quality code. Other developers will work on both of these parts of a project and so, if you are ensuring your JavaScript is easy to read and follow without hundreds of linting errors, why shouldn't your SCSS be the same?

OR as Buzz Lightyear would say it...