(S)CSS and code quality

Intro

Like with any software project, the developer of a CSS project should take care of a nice codebase. This is always important, and especially while working in a team. CSS makes no difference here. The basics of CSS are mostly easy to learn, but with a growing codebase the maintainability can go out of control really quickly without a basic strategy.

A CSS preprocessor like SCSS introduces comfortable and powerful features to help you with that. But with great power comes great responsibility, so we should keep some rules in mind to achieve CSS/SCSS of good code quality.

Quality

Correctness

The styling should match the visual guidelines and requirements. You cannot really test this by looking at the code alone, but you can test the visual outcome in the browser. PhantomCSS or Flux140 are examples for tools that can help you with automated visual regression testing.

There’s also a post about automated visual testing using Flux140 in our blog.

Performance

Rendering performance usually isn’t really an issue. For best perfomance first of all try to avoid nested selectors and keep your selectors simple in general. There’s an in-depth article about selector performance by Ben Frain.

Reusability

Being able to reuse components shows a good modularization of code. There are many great libraries out there with solid solutions for common problems. When using them in a project, take care of clear documenation. For another dev working on your code, it might be really hard to understand where a certain mixin comes from and what it does.

Using variables, functions and mixins help you to keep your code DRY. While I was very excited about placeholders when I started with SCSS (like most people probably), I now tend to agree with Harry Roberts and Hugo Giraudel opinion, using @extend as few times as possible.

For a solid basic styling use normalize.css.

Find global solutions for global problems like z-index, media queries and repeating style patterns. Find the right abstractions and use them!

Maintainability

This is probably the crucial point for any (S)CSS project. Being able to easily make changes or additions to the project without breaking something – even for people who aren’t much acquainted yet with the code – is a very valuable thing. Sticking to the KISS principle is a good idea in general. But adding some structure and methodology to your SCSS can make the difference between failure and success.

One could argue that the code will become harder to maintain in the long run, because introducing new strategies for specific problems will make it more complex. The members of a team might change over the time and might find it hard to get into the concepts added by people, which aren’t in the team anymore.

I think this is an important point of sofware development in general. Having a strategy that adresses a certain problem is better than having none at all, because it represents the knowledge and the understanding of the problems, the software is trying to solve.

Of course a new team member would have to learn about these strategies and this knowledge, that resides in the code, first. But once he or she has achieved that, he can use it to write better code, and might even have learned something about making abstractions. With the premise that strategies are correct and the right abstractions were made, I am convinced that having solutions like that, it will keep code quality high, even with a team that changes over time.

Extensibility

First thing to start with is a clear folder structure, that also represents the architecture of your project. Partials help you to modularize your SCSS here and establish a clear and meaningful structure of your files. Github gives a good starting point for file organization in it’s documentation of Primer. But you should really check if it fits your requirements. In case the project is using a CMS, it might be reasonable to adjust to the structure of it. Also a the structure of a single file should be clear and consistent. It can be really helpful to add a table of contents for big files for example.

The cascading nature of the stylesheets is supposed to help you, but it can become your enemy really quickly, if your aren’t careful enough. Keeping the specifity of CSS selectors low is therefore one of the most important things to keep your (S)CSS maintainable. The selector with the lowest possible specifity is a single class. For this reason some smart people invented the BEM methodology and made it public. The SASS compiler from version 3.3 and up can now also help you writing SCSS in BEM style even more concisely. BEM also avoids side effects.

There are even more strategies to keep specifity low, like nesting selectors. This is also an issue, that is avoided when following BEM correctly.

Tools

Linting your code always helps to keep code quality high. For SCSS there’s scss-lint which can also be used together with grunt or gulp. There’s an example configuration file in the sass-guidelines (which I recommend very much) of a linting configuration file.