SCSS anti-patterns

I’m very much in favor of CSS processing (pre and post) as a useful tool for most front-end development. I’ve used it enough to recognize in retrospect the ways in which mixins and variables can become problematic. Hindsight is 20/20.

General philosophy

CSS is human readable unto itself; clean, documented and organized CSS even more so. So what are the justifications for using a mixin or variable to begin with?

1. Simpler input is processed into more complex output
2. Commonly repeated patterns turned into a typing shortcut
3. Memory enhancement (don’t have to remember syntax)
4. Equalizing a CSS pattern so it can be modified globally

Note that these are mostly aiding the developers who understand them fully and use them regularly. People new to the codebase will at least initially have more work to do, parsing what the various mixins are used for, and what code they are generating. With maybe the exception of (4), none of these improve the code quality.

This points to a general anti-pattern of processing overuse. Have you abstracted your CSS so it’s harder for new developers to participate in? Is the output generated now much more verbose than if you had written it directly? Is your code bloated because mixins are being used as a crutch for CSS knowledge?

Anti-patterns in the wild

Here are some of the anti-patterns I’ve noticed (and/or created 😳) in the past. A gist of code samples with the same names follow.

Abstracted away from clarity

In this case you’ve saved yourself a tiny bit of typing, but you’ve abstracted your CSS and so you’ll need to reference the mixin unless you’ve memorized the order of variables.

Abstraction without processing

This is just hiding CSS, and also forces developers new to your code to reference two places to understand it.

Better handled by Post-CSS

Before we had Post-CSS, a lot of mixins existed simply to handle browser-specific compatibility flags (-webkit etc). Post processing, such as with Auto-prefixer, can take standard well-formed and readable CSS and enhance it with backwards compatibility-enhancing prefixes and syntax after the fact. Maintaining backwards-compatiblity with Post-CSS is preferable from a code readability and comprehension standpoint, as long as the output is checked and the auto-prefixer configuration is maintained.

Overly specific variable

Efficient variable usage is a matter of optimizing the types of values that should be unified and consolidated. Variables are very useful for things like brand colors, especially in template sets that will exist with multiple themes. Overly specific variables are more than likely an indicator of structural inefficiencies. If a variable is so specific that you’d never change it, then it probably shouldn’t be a variable.

Useless variable

A variable that describes it’s own placement and value is a “shortcut” without any benefit. If the value was changed, this would become incredibly misleading.

There’s probably more

I can only imagine what other anti-patterns are out there. The challenge with any powerfully useful technology is to use it responsibly.