When working with CSS preprocessors like Sass, Less (or any other programming language for that matter) you’re going be leveraging the power of variables. However, if you spontaneously create your variable names as you code, the odds are your naming convention will lack cohesiveness. You should think about organizing your variable names (and project for that matter) modularly. This will bring structure and unity to your project as a whole, making it easier to understand and navigate the whole thing.
A Naming Suggestion
Say you need a variable for text color in your project. You could call it
$text-color, or should you call it
$color-text? How do you decide? Choosing one at random can contribute to a lack of structure as the number of variables in your project increases. As experience shows, we often forget exactly how we named variables for particular projects. This leads to confusion and time-consuming methods of global search-and-replace for variable names.
What we need is a rule for defining and selecting our variable names. A great way to keep modularity in your project is to group variables that share relationships and commonalities. Then you can name them by arranging words that describe their function from generic to specific (much the same way CSS works with specificity) from left-to-right.
For example, if I have four variables for four different border colors, I can name them all starting with “border” (as that’s the generic term they all share) and get more specific with a left-to-right reading. Grouping and naming variables in this manner makes your code easier to read, comprehend and recall.
Generic to Specific: An Example
Let’s suppose we’re working in SASS and we want to create a number of variables that define our project’s color palette. If we are working with a shade of blue, we might create some variables like this:
$blue; $dark-blue; $medium-blue; $darkest-blue; $light-blue; $lightest-blue;
A better way to name these variables would be to start with the generic word they all share in common: blue. Then we can get more specific from left to right:
$blue; $blue-dark; $blue-darkest; $blue-light; $blue-lightest;
This not only helps in recollection, but will allow a text editor (such as Sublime Text, Coda etc.) to easily suggest colors. This way you don’t have to memorize exactly how you named your variables. Rather, you can start generically and get more specific as the text editor auto-suggests variable names. All you have to remember is you want a color of blue. So you begin typing
$blue and you can get a list of all the different blues you’ve created!
Imagine I’m working on a large project and I’ve grouped all my variables that contain color values by prefixing them with the generic word they all have in common: color.
// OK $border-color; $dark-border-color; $light-color-border; $highlight; $link; $link-dark; $text; $color-text; $link-color-light; $lightest-text-color;
// Better $color-border; $color-border-dark; $color-border-light; $color-highlight; $color-link; $color-link-dark; $color-link-light; $color-text; $color-text-light; $color-text-lightest;
Then, let’s say I needed a color for a border. I begin typing
border: 1px solid $colo and my text editor can suggest all the color variables I’ve defined for my project.
Perhaps I have a lot of colors in my project but I only want border colors. I could pre-define a few variables with my desired border colors. Then, when coding, I can simply continue narrowing the specificity of my variable name
border: 1px solid $color-border and my text editor will auto-suggest any variables I have by that prefix. All I have to do is chose the one I want!
Even if you didn’t have code hinting, this would still be an effective way of naming your variables. It helps you easily recollect what you’ve named variables because variables that share relationships share prefixes.
Naming your variables in this modular way will help you understand your project conceptually before you code, while you code, and after you code. It’s a win-win-win situation!