Sass Do's and Don'ts

Why Side-by-Side Comparisons Help

Seeing the "don't" and the "do" next to each other makes the reasoning concrete and immediately actionable, rather than abstract advice. Each pair below reflects a genuinely common pattern seen in real Sass codebases.

// Don't
@import 'colors';
.btn { color: $primary; }

// Do
@use 'colors';
.btn { color: colors.$primary; }

The "Do" version gains namespacing, single-load guarantees, and future compatibility as @import moves toward removal.

How to Use This Reference

Don't: <problematic pattern>
Do: <recommended alternative>
Why: <the underlying reasoning>

• Each pair below shows a common problematic pattern next to its fix.
• The reasoning matters more than memorizing the fix itself, apply the same thinking to new situations.
• Not every "don't" is strictly wrong in every context, but each has a clearly better default.

Sass Do's and Don'ts Cheatsheet

Quick comparisons across the most common Sass decisions.

Module System

Don't continue writing new @import statements. Do migrate to @use/@forward, which provide namespacing, single-load guarantees, and private members, none of which @import supports.

Nesting and Selectors

Don't nest five or six levels deep chasing a visual hierarchy match with your HTML. Do use BEM naming combined with &, which keeps selectors flat, low-specificity, and easy to override.

Reuse: Mixins, Functions, and Placeholders

Don't reach for a parameterless mixin purely to avoid retyping a few lines. Do use a placeholder with @extend for fixed, unvarying styles, and reserve mixins for anything that genuinely needs parameters.

Common Mistakes

• Following a "don't" out of habit long after learning the recommended "do" alternative.
• Applying a "do" rule too rigidly in a case where the "don't" pattern is actually the more pragmatic choice.
• Not sharing this kind of reference with newer team members, causing inconsistent patterns across a codebase.
• Treating these as absolute rules rather than strong defaults that still require judgment for edge cases.

Key Takeaways

• Side-by-side comparisons make Sass best practices concrete and immediately actionable.
• Module system, nesting depth, and reuse-tool choice are the areas with the clearest do/don't guidance.
• These are strong defaults, not absolute laws, use judgment for genuine edge cases.
• Sharing this kind of reference across a team keeps a codebase consistent as it grows.