こんにちは、@ayanerv_2045です。
株式会社エイチームウェルネスのデザイナーで、主な業務なグラフィックデザインですが、時々HTML・CSSやjQUeryなど小規模なフロントエンド部分も触ります。
Qiita記事執筆はとても久しぶりなので（怠惰）、お手柔らかにお願いします。

本記事は Ateam Finergy Inc. × Ateam Wellness Inc. Advent Calendar 2023 の9日目の記事です

これは何

この記事は、下記のようなことで困っている方に向けて書いた記事です。

いろいろなCSS設計思想が存在するのは知っているけど、なかなか覚えられない
担当プロジェクトやチームで書いているコードに設計思想・命名規則が特にない
でも少しでも保守性は高めたいので、無難で汚くないCSSを書きたい
もうなんでもいいから、最低限、周囲に迷惑をかけないCSSを書いておきたい！

　
要は、様々な事情によりキッチリ規則を定めたCSSで開発・保守することが困難だけど、自分や他のメンバーのためにできるだけ読みやすいCSSを書きたい人向けです。
　

ご注意
何か画期的な設計・命名規則などを提唱する記事ではありません。
私はこういうポイントを気にしてCSSを書いているよ、少しでも誰かの参考になればいいな…という記事ですのでそこはご容赦ください。

これが「最低限、周囲に迷惑をかけないCSS」だ！！

目的が近いプロパティは近くに書く
命名の記法を揃える
rem, emを使わない
タグに直接指定しない
margin, paddingはつける方向を揃える
margin, paddingはまとめる
複雑なcalc()にはコメントを添える

順に説明していきます。

1. 目的が近いプロパティは近くに書く

「どうスタイリングしたいか」に基づいて、目的が近いプロパティを近くに固めて書くだけでもかなり読みやすいCSSになります。

大きさ、文字、余白、位置調整など、色々なプロパティが絡み合うCSSにおいて、せめて「このクラスは幅と色を指定しているな」ということがパッと見でわかるだけでもありがたいものです。
そこでこの「目的が近いプロパティを近くに固めて書く」が地味ながら大切になると考えます。
　
下記のサンプルコードgood.cssはプロパティを目的ごとに連続する行に固めて書いたもの、対してbad.cssは心の赴くままに書いたものです。
なんとなくgoodの方が「何をしようとしているのか」を解読しやすいように感じませんか？

good.css

.button {
  width: 100%;
  position: absolute;
  top: 50%;
  padding: 16px;
  margin: 0 auto;
  font-size: 16px;
  font-weight: bold;
  line-height: 1;
}

bad.css

.button {
  width: 100%;
  margin: 0 auto;
  font-weight: bold;
  position: absolute;
  line-height: 1;
  top: 50%;
  padding: 16px;
  font-size: 16px;
}

上から順にサーッと目を通しただけで、大きさ、絶対位置、余白、文字周りの指定をしていると直感的にわかるのではないでしょうか？

この書き方は表示崩れを起こしてしまった時の調査も簡単になります。
「文字サイズが変なので、文字サイズを指定しているAクラスが怪しいぞ」
という感じで、怪しい箇所の特定がざっくりできます🙆‍♀️　

ただ、チームによってはアルファベット順を採用している場合もあると思いますので、その場合は必ずしも目的ごとに並べる必要はありません。

2. 命名の記法を揃える

むちゃくちゃ初歩的じゃん！と思われるかもしれませんが、大事です。
クラスやidの書き方を揃えると、いちいち違う記法を読む頭に切り替えずに済むので、自分にとってもチームにとっても可読性が上がります。

下記のうちどれか一つの命名規則で統一するようにしましょう！

記法の名前	サンプル
キャメルケース	sampleClassName	先頭以外の単語の頭文字を大文字にする
パスカルケース	SampleClassName	すべての単語の頭文字を大文字にする
スネークケース	sample_class_name	単語をアンダースコアで連結する
ケバブケース	sample-class-name	単語をハイフンで連結する

私はスネークケースが好きです。
単語の間に隙間があって読みやすく感じますし、言語によってはハイフンがマイナスとして解釈されることもあり普段あまりハイフンを使わないため、アンダーバーの方が親しみがある（？）のが理由です。

3. rem, emを使わないようにする

主にfont-sizeの指定に使う単位のremとemですが、これらはチーム内でキッチリとコーディング規約が整備されている場合しか使わないことをおすすめします。

remとemは、どちらも相対的にサイズを指定する単位です。

単位	意味
rem	ルート要素（html要素）のfont-sizeを基準としたとき何倍相当かを表す
em	親要素のfont-sizeを基準としたとき何倍相当かを表す

相対的にサイズ指定をするということは、参照する要素のfont-sizeが変更されるとそれに合わせてサイズが変更されるということ。
コーディング規約が浸透していないチームでこれを使うと、参照元の要素をいちいち見にいく必要がありますし、ネストが深い場合はどの親要素を参照しているのか探す面倒もあって、混乱の元になります。

どうしても使う必要がある場合はチームで相談し、できたらコメントやドキュメントで簡潔に意図を書き記しておくと良いかなと思います。

4. タグをセレクタとして使わないようにする

タグをセレクタ（スタイルを当てる対象をタグの種類で指定すること）にしてしまうと、混乱の元になったり、CSSのコードが長くなりがちです。

例えば下記のようなコードのことです。

very_bad.css

/* aタグをセレクタにして指定 */
a {
  color: #0070f3;
  font-size: 16px;
  text-decoration: none;
}

/* 親要素のクラスやidを介してaタグ指定 */
.sample a {
  color: #0070f3;
  font-size: 16px;
  text-decoration: none;
}

これをすると保守性の低いCSSになってしまう理由は、
タグ指定のスタイルは影響範囲が広く、打ち消すスタイリングが必要になる
からです。
タグを指定すると影響範囲が広くなるというのは想像しやすいと思いますので、ここでは打ち消すスタイリングのデメリットにフォーカスして説明します。

下記のコードは、

デフォルトのaタグは「太字、アンダーライン無しのリンク」
.link_sampleだけは「細字、アンダーラインあり、赤字のリンク」

にしようとしています。

bad.css

/* 太字、アンダーライン無しのリンク（デフォルト） */
a {
  font-weight: bold;
  text-decoration: none;
}

/* 細字、アンダーラインあり、赤字のリンク */
.link_sample {
  color: #ff0000;
  font-weight: normal;
  text-decoration: underline;
}

まずaタグを指定して「太字でアンダーライン無し」のスタイリングをした後、.link_sampleだけを指定してfont-sizeを通常に戻し、text-decorationを下線ありにしているのがわかるでしょうか。

これが打ち消すスタイリングです。

このサンプルコードではまだリンクの種類が少ないのでマシですが、この書き方をしたままこの後さらに見た目が違うリンクを作りたくなったら、どんどん打ち消す記述が増えて、コードが膨大になっていくのです…。

打ち消すスタイリングをやめる一番の近道はタグをセレクタとして使わないようにすることです。

good.css

/* 太字でアンダーライン無しのリンク（デフォルト） */
.link_default {
  font-weight: bold;
  text-decoration: none;
}

/* 細字、アンダーラインあり、赤字のリンク */
.link_sample {
  color: #ff0000;
}

デフォルトのスタイルも、.link_sampleのスタイルも、どちらもクラスで指定するように変更しました。
aタグに指定していたfont-size、text-decorationを打ち消す必要がなくなり、おかげで.link_sampleの記述量が減っていますね。

個人的に、タグにスタイルを当てているCSSに遭遇するとマジでショックです。
(でもチームのコーディング規約に則っているならOKで〜す👍)

~~あと世の中のSaaSはいますぐタグ直接指定をやめてほしいな…（自社開発のスタイルを知らん間に破壊してくるので）~~

5. margin, paddingはつける方向を揃える

要素に対して余白が付く方向を揃えると、自分の次にCSSを書く人が楽になります。
「上マージン」「下マージン」のどちらが良いか、みたいな話をエンジニア同士で議論したことはありませんか？
それのことです。

特にmarginはpaddingと違って隣の要素どうしで重なってしまうことがあるため、結局どちらのmarginの距離が正しいのか分かりづらく、リファクタリング時の障害になります。

上下左右どの方向に余白を設けると良いのか、前任者のコードを読んで空気を読む、またはチーム内で認識を揃えることで統一しておくとGoodです。

6. margin, paddingはまとめる

シンプルに記述量が減るだけでも可読性、保守性は上がると考えています。
marginとpaddingはなるべく一つのプロパティにまとめるのがおすすめです。

good.css

.button {
  margin: 8px 12px 16px 12px; /* 左右で値が同じなので、最後の12pxは省略可 */
}

bad.css

.button {
  margin-top: 8px;
  margin-right: 12px;
  margin-bottom: 16px;
  margin-left: 12px;
}

7. 複雑なcalc()にはコメントを添える

これは本当にタイトルのままです。
サイズや位置の計算に便利なcalc()ですが、あまりに複雑な計算式や、どこからとってきた数値かわからないものを元に計算する式を書くと、後任者を困らせることになります。

例えば下記の2つのcalcで言うと、上のcalcは「画面幅から左右のmargin分引いているのかな」となんとなくわかると思いますが、下のcalcは式が複雑な上にそれぞれの数値がどこから出てきたかわからないと困ってしまいます。

sample.css

/* Good */
width: calc(100vw - 24px);

/* うーん… */
width: calc(10px + (100% - 24px));

どうしても複雑なcalcが必要な時は、簡潔にコメントを残して何を計算しているのかがざっくり伝わるようにすると良いでしょう。

8. Tailwindを導入する

それを言っちゃおしまいよって感じなので、前述のリストにはあえて入れませんでしたが…。

正直これが最強だと思っています。
当初は自力でキッチリ命名規則を守って美しいコードを書くことに固執していた私も、今ではもうみんなTaiwind使えばいいよって思うくらい便利です。

Tailwindを導入すると、こんないいことがあります

命名を考えなくて良くなり、開発スピードが上がる
用意されたクラスを組み合わせれば自由にスタイリングできるので、他のライブラリやフレームワークと違ってデザインに制限がかかりにくい
誰が書いても大体同じようなコードになり、コード品質のバラツキ予防になる

特に命名を考えなくて良くなるのがメリットとして大きいので、命名に困ることが多いチームでは導入を検討してみてください。

と、言いつつ私自身まだTailwindの上手な説明を具体的にできる自信がないので、気になる方は公式ドキュメントのサンプルを見てみてください☆

Tailwind公式ドキュメントはこちら！
サンプルコードも多くて分かりやすいです！

結局大事なのは「配慮」

ここまで普段私が気をつけている「最低限、周囲に迷惑をかけないCSS」について説明してきましたが、結局一番大切なのは、次にあなたが書いたCSSを触る人への配慮・未来の自分への配慮ではないかなと思います。

こっちの方が読みやすそう、こっちの方が記述量が少なくて済む、というような小さな配慮を積み重ねて、そして空気を読んで統一感あるコードを書けば、決まりがなくてもある程度は綺麗なCSSになるはずです。

世の中にある素晴らしい命名規則、設計思想を参考にして美しいコードの書き方を学びつつ、「そうは言っても全部は覚えられないよ〜使いこなせないよ〜」となった時は、この記事を思い出していただけたら幸いです。

お読みいただきありがとうございました！