When your project grows up, especially if it is a startup, when all modules, and main assumptions of how it should work or how it should look like have been changed lot of times, there always is a moment, when your styles become a mess. Is there a way to avoid it? So, not really, but we can soften it, and make it simple to clean it up.

Sass naming conventions allow us to keep our code clean and readable as long as possible, however that isn”t enough. The main problem is, that naming is the most debated thing in developing, no matter what language do we talk about. Many people deal with naming as hobby, but the same amount treat it as an art! For some people there is nothing more important, however I”m not agree with them… at least not completely.

I like reading about conventions and refactor my own code sometimes but only for getting used to type properly clean code on a regular basis. About stylesheets, I often do not create my own names, but use existing from most knowing styling frameworks, like Bootstrap or Foundation.

Well, if so, why simple don”t use those frameworks? Basically when you want to create unique project with lot of styling, you often need to overwrite most of default library styles. Then your code size is doubled, so user needs to wait longer for loading the page. When you use turbolinks or jQueryMobile, this problem appears only for first page load, hovewer for google it exists for every request. As far, as your project grows, performance is more and more important, so often the better solution is to write your own stylesheet from scratch, rather than use some existing library.

In this article I will explore those methods of keeping styles clean I prefer to use in my projects.

Think about sass resources in terms of objects

When I write code in rails on any other objective language, the most important to keep my code clean, is to think about resources as objects. In sass part you can and should do the same. Sass projects can be designed in modular way, and we should think about parts of our views as objects.

Sometimes objects are called modules ( for example SMACSS do it this way). I don”t like it, because as far as I”m a backend developer, in other technologies ”modules” have their own, different meaning. Honestly in sass, modules are also used to name libraries and sets of styles included to our files. I don”t like confusions and thinking about ”what the author had on his mind”, so when I talk about modules, I use this term but resources, classes, and other pieces my projects are always objects for me.

Here is a button object example got from bootstrap library:

I used bootstrap example rather than writing my own here, to show you the reason, why sometimes using libraries is not good idea. Do you see, how many attributes has this single object? Maybe in your application most of them will be overwritten, and then whole code will be duplicated. Imagine the situation, when you need to override thousands lines of code. Make difference, doesn”t it?

I would like to my objects using class selectors. I avoid styling raw element selectors or even ids, because css specifity causes lot of problems when our styles become more complicated. Element selectors I use only to specify main, shared with whole application styles for those objects.

The line @extend %headings !optional  is optional, it allows me to use %headings  as any other selector, which all h*  sellectors in one.

Naming conventions for sass modifiers

Modifier is a type of class which describes if the object is in specific state, or there should be some little change in general state (for example background-image  for disabled buttons). I ofter use modifiers to specify the size of differrent objects, here:

Lot of popular naming conventions use is-  prefix, but I don”t like it, because adjective is precisely enough to describe object state. I don”t use adjective as object names, and so on don”t use nouns for naming modifiers, so all code remains consistent.

As far as I don”t recommend nested naming in sass, I often use ampersand to specify modifiers. The reason is, that I don”t want those changes to affect other .large  elements in the app. Maybe I would like to create large image, or large header, which will have other dimensions. This rule is common for modifiers, so I suggest to always define them inside parents” definitions.

Jonathan Snook in his talk “Your CSS is a mess” said differrent and gave lot of pros to proove his way of thinking, however for me there is so much easier to just add ampersand that I allow Git pull request context to be quite confusing.

Do not use Hyphens in object names

Why? Well, I really recommend to watch the video above to understand conventions mentioned here in details. Using hyphens in object names is quite confusing, because nesting in CSS is evil. Going deeper into this statement, your code become ambiguous when you try to specify many parent-child relations next to two-words object names. When I check code on pull request, when I can see only three lines above and three lines below changed code, I would be glad to know in an instant, what the changed code does. This is why I want to know which one class describes root object, which one is an selector, and which one is the child.


As far as I user ampersand to describe modifiers, the whole code remains readable all the time, no matter how much my applications grow. I don”t expect you to use all of the rules above entirely and don”t recommend that. No matter how many naming conventions will you ever find, you always should think what will be the best for you and your apps and adjust all advices, however I hope this article will help you keep your CSS code clean and extremely easy to manage.

Shares
Share This