SCSSのネストをやめてみたら見えた世界〜保守性と可読性のための一歩

2025.07.22 09:00
2025.07.22 09:18
SCSSのネストをやめてみたら見えた世界〜保守性と可読性のための一歩

はじめに

SCSSを書くとき、ついネストを深くしてしまうことが多いですよね。
親のクラスに書いておけば楽だし、見た目も「まとまってる感」があって。
僕もずっとそんな感じで書いていたのですが、あるとき「これ、本当にメンテしやすいのか?」と疑問を持ちました。

思い切って「ネスト禁止・全クラス明示記述」というルールにしてみたら、予想以上に世界が変わったので、その記録を残しておこうと思います。
あまり詳しくない僕が調べて試した結果なので、参考程度に読んでもらえたら嬉しいです。

ネストしていた頃の悩み

最初はネストが大好きでした。
親のブロックにまとめて書けるし、スッキリしてるし、便利!って思っていたんです。

でもプロジェクトが大きくなっていくと、

  • どこがどこに効いてるのかわからない
  • 同じクラスが別の場所で定義されていて競合する
  • 消していいのか怖い
  • コードがどんどん右に寄っていく(笑)

こんな悩みが出てきました。

ネスト禁止ルールにした

そこで、思い切ってネストを禁止してみました。
具体的には以下のルールです:

  • すべてのクラスはトップレベルで書く
  • 子要素もBEM記法で .block__element と書く
  • SCSSファイルはFLOCSSで分ける
  • ネストは疑似要素や@mixinに限る

Before(ネストあり):

.block {
  &__element {
    color: red;

    &:hover {
      color: blue;
    }
  }
}

After(ネストなし):

.block__element {
  color: red;
}

.block__element:hover {
  color: blue;
}

やってみてよかったこと

実際にやってみると、いいことがたくさんありました。

  • どこで定義しているか一発で見つかる
  • コードの移動や削除が怖くない
  • 競合がほとんど起きない
  • 他の人が見ても理解しやすい
  • 未来の自分にも優しい

特に「競合が減った」のは大きくて、デバッグがだいぶ楽になりました。

困ったこと・工夫したこと

もちろん、困ったこともありました。

  • 記述量が増えた気がする
  • ファイルが増えたので命名に迷う

でも、スニペットやVSCodeの補完機能を使ったらだいぶ楽になりました。
命名もFLOCSSの役割ごとにフォルダを分けるようにしたら管理しやすくなりました。

まとめ

ネストをやめるのは最初ちょっと勇気がいりますが、やってみると長期的にはとても快適です。
小規模のプロジェクトや試作段階ならネストしてもいいと思いますが、本番で育てていくサイトならおすすめです。

次はこのルールに加えて space-mapcolor-map ももっと活用していきたいと思っています。
もし「最近SCSSがごちゃごちゃしてきたな」と感じていたら、ぜひ一度試してみてください。

今回は以上です!