May 24, 2022

SASS best practices to avoid a frustrated developer: beginner level

How many times have you started working on the maintenance of a project that was abandoned  long time ago?, or how many times have you been hired to make a new functionality in a website that hasn’t implemented any CSS preprocessor?

Well, I think all front-end developers have faced not one but many times this difficult situation where you don’t know even where to start, and the worst part is that most  times you want to throw everything away because you think there is always a better way of doing things.

No doubt that there’s always a better way of doing things and this article is about that, it has as objective to encourage the use of CSS preprocessors such as SASS, LESS or STYLUS. So here you will find some of best practices of SASS to create maintainable CSS code.

It is very important to always keep in mind that other developers will read our code and they’re going to make a big effort to understand it, so don’t forget that the machine, doesn’t matter how, always will understand your source code but another developer may not, so for the sake of the community please follow some of best practices with SASS.

Let’s begin…

First, structure your files and folders in an organized way:

Sometimes we will work with external libraries that should be separated from our source code, also we must have a main.scss file where other SCSS partial files will be imported. Try to separate your MIXINS, functions and variables in a separated file. Here you can see an example:

dist/
   |- js/
   |- css/
       |- main.min.css
source/
   |- scss/
       |- main.scss
       |- _variables.scss
       |- _mixins.scss
       |- _layout.scss
       |- _grid.scss

Second, use the variables more effectively:

You shouldn’t name variables in a very vague way, they should be used in a very general way throughout the whole project, for example:

$red: #DA1616;
$blue: #161BD2;
$primary-title: $blue;
$secondary-title: $red;

Some bad examples are:

$link: #FFA600;
$listStyle: none;
$radius: 5px;

Third, reduce the use of MIXINS that duplicate code:

Using a mixin is the equivalent of copying and pasting code from one place to another, and we don’t want to have duplicated code everywhere. We should only use a mixin if an argument is used, meaning that it should be used for example, to create a title with different font sizes.

@mixin primary-title ($fontSize) {
   font-family: Quicksand;
   font-weight: 600;
   font-size: $fontSize;
}

.blog-title {
    @include primary-title(15px);
}
.page-title {
    @include primary-title(19px);
}

Fourth, let’s use more placeholders:

Unlike mixins, placeholders can be used many times without adding duplicated code and this makes our CSS code much lighter and effective.

%title-small {
   font-size: 15px;
   font-family: Roboto;
   color: #F2F2F2;
}
.blog-title {
   @extend %title-small;
}
.page-title {
   @extend %title-small;
}

When compiling the SASS code, the CSS that we obtain is something like this:

.blog-title, .page-title {
   font-size: 15px;
   font-family: Roboto;
   color: #F2F2F2;
}

The same example using mixins would be like this:

@mixin title-small {
   font-size: 15px;
   font-family: Roboto;
   color: #F2F2F2;
}
.blog-title {
   @include title-small;
}
.page-title {
   @include title-small;
}

When compiling the SASS, the CSS that we obtain is the following:

.blog-title {
   font-size: 15px;
   font-family: Roboto;
   color: #F2F2F2;
}
.page-title {
   font-size: 15px;
   font-family: Roboto;
   color: #F2F2F2;
}

Fifth, use functions to do mathematical calculations

The functions are used to make calculations, a SASS function does not return any CSS code, however it does returns a value which can be used in CSS. For example we want to calculate the width of a column in a row.

@function calculate-width ($col-span) {
   @return 100% / $col-span
}
.span-two {
   width: calculate-width(2); // spans 2 columns, width = 50%
}
.span-three {
   width: calculate-width(3); // spans 3 columns, width = 33.3%
}

Always keep your files and folders organized, placeholders, mixins and functions in one file and variables that will be used throughout the project in another in order to be maintainable and reused in the future, here you should have types of fonts, colors and rules for different types of titles, among others you consider appropriate.

It’s imperative to avoid using many levels of immersion in your SASS code because it is not good practice to have more than 3 levels, check this out:

.class_one {
   display: inline;
   .class_two {
       display: inline-block;
       .class_three {
           display: table;
       }
   }
}

In summary, try to keep things simple, remember that the purpose of SASS is to write better and more manageable CSS code and before creating a new mixin, placeholder, variable or function make sure it is really necessary and always ask yourself how you can do it in a more general and maintainable way.

Surely you have your own tips or way of doing things, I know and understand that we do not all think the same, but that’s precisely why some basic rules must be followed when working as a team or working on a project that in the future will be taken by another developer, we don’t want this one suffering when trying to understand the code we wrote.

Cheers!

Other posts

This is the story of a service we created in-house, tested it, and ultimately decided to retire. The germ for the idea came from our own experience in digital marketing, where we saw an opportunity. We succeeded to a certain point however there were too many factors outside our control. Ultimately we failed to find an attractive revenue model, and this article explains our decision to retire the project, and the valuable lessons we learned along the way.
January 25, 2024
John Oliver Coffey

Datapico: the trials, the successes and the decision to close it down

This is the story of a service we created in-house, tested it, and ultimately decided to retire. The germ for the idea came from our own experience in digital marketing, where we saw an opportunity. We succeeded to a certain point however there were too many factors outside our control. Ultimately we failed to find an attractive revenue model, and this article explains our decision to retire the project, and the valuable lessons we learned along the way.

Read more

Do you have an idea? Let’s talk about it.