Over a million developers have joined DZone.

Don't Be Petty, Write Less Spaghetti!

Clean, maintainable code is one of the hallmarks of a strong developer. Find out what this means for CSS here.

· Web Dev Zone

Download this free eBook to learn how to build robust JavaScript applications and ensure effective error monitoring is in place, brought to you in partnership with Raygun

CSS to CSS Preprocessor?

Are you transitioning from regular CSS to a modular CSS preprocessor? Or, perhaps you’ve just started using a CSS pre-processor?

If so, you may be able to relate to the following:

  • Writing CSS is easy
  • Writing CSS for a one-off large scale project is easy
  • Writing CSS for a large scale project with multiple people working on it… isn’t.

It’s often the case that there’s no structure. You’re constantly running into cascading problems and having to write classes that undo conflicting parent styles.

Refactoring is a mess, as you’re jumping all over the place. And it’s not maintainable.

I.e. – spaghetti.

However, it doesn’t have to be this way!

This article will help you and your team write maintainable CSS that you can iterate and develop on. I’ll share some techniques that have got me out a messy spot more than once!

First... What Is Spaghetti CSS and How Can We Avoid It?

One of the best parts, if not the best part of using a CSS preprocessor is the ability to create many sub-stylesheets.

Used correctly this is awesome, but used incorrectly, this could  be your worst nightmare…

So let’s go into what I call spaghetti:

  • Nested/tangled classes/CSS
  • Unorganized/unstructured code
  • Quick to write; impossible to maintain

However, this is the CSS we want:

  • Small, maintainable, modular stylesheets, each with their own purpose.
  • Stylesheets that remain 100% independent from one and other.
  • Has very maintainable code.

Let’s look at some common traps I fell into when I started writing SCSS:

How to Write Spaghetti Code (Not Good!)

One of the first things I did when I started writing SCSS was to break apart my main.css file into sub stylesheets using the @import feature.

(tip: If you name your @imports starting with an underscore, preprocessors won’t generate a file for them! E.g. @import “_sub-stylesheet.scss”.)

This in itself was great, and my second favorite feature.

However, my favorite feature was the wonders of nesting classes.

You may recognize:

// _page.scss
// --

.home-page {
  .button {
    // Behave in a custom way


This was by far my favorite feature of SCSS... I found doing this sped up my spaghetti output by a factor of ten! It was great in the short term, but I wasn’t aware of how it would come around to bite me in the near future.

I wish I knew the problems I was creating for future me.

I thought I was safe.

Then, it happened.

Here’s how it went down:

A common element that was used everywhere throughout our site was redesigned. It wasn’t a big change, but because of how I had modified the element to work in certain scenarios, I had to update the element across several stylesheets.

I couldn’t safely delete the:  

  • Dead code
  • Unable to delete
  • Tracking down every use case took a long time.
  • Unintended reliance.

Safe to say, I learned my lesson. Here’s what I learned...

How to Write Better CSS Code

The idea behind modular CSS is to write specific styles that serve a single purpose within a given scope with less general classes you use to mix and match to get your desired effect.

I did this to a point, however, I set out some specific rules:

  • No nesting
  • Remove cascade
  • Each DOM element has a single purpose

Here’s a hypothetical scenario and how you could approach it:

For all the examples in this post, I’ll be using the BEM methodology (one of many modular methods for writing CSS)

For this example:

  • Variables.scss - A stylesheet for global variables.

  • Block.scss - “Blocks” are  simple,reusable,standalone block with a single purpose, such as a button / icon / avatar.

  • Component.scss - Components are reusable, but are more complex that blocks, they often consist of blocks. E.g. accordions / dropdowns / modals.

  • View.scss - A stylesheet specific to a page.

The Task

Image title

An unstructured example…

What I’m trying to show in the above graphic is the all too familiar connections created by spaghetti modular CSS (bad).

By nesting classes inside of other classes, I have not only created a specificity battle, but created a reliance on multiple stylesheets. At a small scale this seems manageable, but when it comes time to refactoring and deleting this code, it’s awful—even as the author.

Lots of cross file references... tracking down what’s changing becomes a maze. When it comes to deleting dead code, it now also tangles with code that could be being used anywhere. The goal with modular CSS is to reduce dependencies.

If I wanted to update block on view, I’d have to remember to go to the view to make the change, but then if I reused that style, it’s now not specifically linked to that stylesheet.

Also: I can’t count the number of times I have been told:

This color will ONLY be used here.

Even so, be consistent.

Variables like colors have a very high tendency to be used all over the place, so structuring them in a way that facilitates letting you using them anywhere is key.

Now the Same Task But Modular CSS:

Image title

A structured example…

Rethink the Tasks

One of the first things you have to do when given a list of changes is to  take a step back.

Think about the larger picture with modular CSS.

Instead of making “component” just plain bigger on a specific view, control the component within the component stylesheet—by creating a state for it.

What this means it that you have now created an “option” for the component, not tied to any view, free to be reused wherever you want.

This also keeps all CSS relative to the component contained within a single .scss file.

Writing modular CSS in this way allows you to scale the codebase easily  (and promote reusability) as you don’t have to hunt to find different versions of X, they should all be contained within their own stylesheets (and independent of one another).

Everything being modular also allows multiple people to work on the same files at the same time.

As you can see in the above image, there is no dependence between the stylesheets (Other than variables). This means when “block” is deemed dead code, you can safely delete the file with no cross file repercussions.

Conclusion of Our Experiment

Yes, the outcome is the same for both examples.

However what’s important to remember is unorganized and messy code (even though fast) introduces unwanted complexity, offers less options down the track, and promotes duplication if you want to reuse any of the styles and have them somewhat organized.

TIP: To change an element for a specific case, write a modifier class for the element, never change something that was not created in the stylesheet you are modifying.

As another example, let’s take a look at this piece of spaghetti code:

.view .component .block {
  // really specific code controlling block.

It’s hard to maintain spaghetti code like the above.

It’s also a performance nightmare.

This small example would require the browser to make three fetch attempts across the DOM before being able to render all the changes.

You can read more about this here:

The end result of adding a single selector is minuscule, but multiply this over an entire codebase and you can inadvertently add seconds to your page rendering time!

So, how do we get started on writing less spaghetti?

Getting Started

So, you’re probably wanting to get started.

I recommend the following steps:

  1. Find a set of rules and enforce them.
  2. Start with a small project to get used to how things should work.
  3. Don’t make exceptions to the rules! If something doesn’t bend the way you want, create a new stylesheet and make the thing you want from scratch.
  4. Try and reduce classes within classes as much as possible (in CSS that is).

Changes made to a block element should be done so with a class on the respective block or element, not their parent.

If it needs to look different, decide whether it should be done via a state class modifier or by creating a new component.

Tip: If you name an SCSS file starting with an underscore e.g: “_class-name” it won’t generate a CSS file.

A Simple Folder Structure to Get You Started

Writing modular CSS takes a fair bit of getting used to. Start with a small, small project.


  • Never reference other stylesheets from within one and other.
  • Never create classes within classes.
  • If the same component is needed in multiple places, make it reusable and modify it using state classes.
  • Try and not use classes to remove styles; create a base block/component and add to it.

Note: Rules are made to be broken, but do so wisely, and enforce them!

All Files Are Included Inside main.scss.

Since every stylesheet is independent, you should never need to be including files inside other included files.

This just creates complexity for no reason.

Create five primary folders.


  • Colors.scss
  • Helpers.scss
  • Mixins.scss
  • Breakpoints.scss


// Reusable styles that change the layout of a page.

  • Grid framework
  • General layouts


// Blocks are stand alone elements, able to be used by themselves as well as by components. Usually created by a single DOM element.

  • Buttons
  • Icons
  • Avatars


// Components are reusable, but contain multiple blocks.

  • pagination
  • accordions
  • Modals
  • Modules


If a page cannot be completed using reusable styles, or you need to create specific styles for ONLY this view, (never to be reused, 100% sure)  add a stylesheet named after the view, and write the css here.

// You’re the best judge of your own system, add/remove folders at will!

A Few Tools to Help You on Your Way:

  • If you’re using a preprocessor, I recommend checking out autoprefixer, never worry about writing browser-specific CSS ever again.
    • You can use tools such as KSS to generate a style-guide straight from your CSS, and since all your components are split up per file.
    • Autoprefixer (I can't stress this enough!)

    In Conclusion…

    Here are some popular modular CSS methods:




    Atomic Design

    As with most things, there is no silver bullet that will solve all your modular CSS problems.

    The major takeaway from this article is no matter which method you are using, it’s important to make sure what you are writing is tidy and maintainable, with small modular stylesheets—each with their own purpose and that are independent from each other.

    And above all...

    Don't be petty, write less spaghetti!

    Download this free eBook to learn how to implement an effective ChatOps workflow to make issue management and resolution easy within software development teams, brought to you in partnership with Raygun.

    css,spaghetti code,clean code,modular css,css preprocessor,design,web dev

    Published at DZone with permission of Gary Tuohy, DZone MVB. See the original article here.

    Opinions expressed by DZone contributors are their own.

    The best of DZone straight to your inbox.

    Please provide a valid email address.

    Thanks for subscribing!

    Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

    {{ parent.title || parent.header.title}}

    {{ parent.tldr }}

    {{ parent.urlSource.name }}