Please avoid these variables! Better practices…
What is a variable?
Variables are very handy strings that, as the name suggests, can vary or change one day. They can be called from many places and in many ways to be used and reused (depending on the coding language).
What makes them handy is: When you need to change one, you only need to change its value in one place, the new value will then pass to every location where you called the variable, by its name.
| Coding language | Variable construction |
|---|---|
| CSS | var(–name) |
| SCSS & PHP | $name |
| JavaScript | var name const name let name |
What to avoid in a variable name?
Even if a variable suggests a change, I see many times developers using names such as $white in SCSS or var(–white) in CSS. This for me doesn’t make any sense… How am I supposed to change to a value other than white?
Even if we can change the colour value, and it visually applies as expected, the code will be illegible. It will be read “white” when it isn’t. For example, it doesn’t make sense to have a #cecece on a $white variable.
It stops being a real variable.
It would be much better to call it $light, so it could be changed to any light colour on future design system changes. You might think this would still limit to a certain type of colour, and you are right, but at least it can vary as the name suggests.
And we could always take this to another level, call it $secondary_colour or $colourTertiary, so we could use any colour, making it future-proof as long as it’s not confused with the main/primary one.
We will recap with more examples below…
Use a standard method on the names
Be consistent when giving a name, stick to one method on all your coding or, at least, depending on the code language.
On PHP, it is typical to use underscores on variables with two or more words, on JavaScript the camel case method is more typical and on CSS the hyphen.
But if you can stick with only one method on all coding languages, it’s even better, I would say.
My favourite nowadays is camel case, so something like this: $colourPrimary.
Make it scalable with a convention!
Another tip, but very optional, is to set a convention to make the variables more scalable.
For instance, start the name with the property type and only then the actual name in camel case. In this situation, you can even combine underscores with camel cases. Here’s what I mean:
- $colour_PrimaryLight.
- $size_Spacing2 (don’t use “margin” on the name, that way you can reuse that size on paddings and font-sizes).
- $size_font_TitleBig (create another “layer” to say that this specific size is to be used only for text).
This will avoid conflicts, mistakes and make certain variables easier to find when you have a lot of them.
Quick recap
| Avoid | Regular name | Better name (future-proof) |
|---|---|---|
| light | colour_TertiaryLight | |
| margin2 | size_Spacing2 |
