Web制作を学んでいると、必ずぶつかる壁が「コードの書き方」と「クラス名の付け方」ですよね。動くサイトを作れるようになると、「とりあえず動いたからOK」と思ってしまいがちですが、数日後に自分で見返して「え、これ何書いてるの？」ってなることありませんか？
私はまさにそれでした。最初のころは、box1とかred-textとか、思いついたままクラス名をつけていて、後から修正しようとしたときに全然意味がわからなくなって…。「自分の書いたコードなのに、なんで理解できないんだろう」って落ち込んだこともよくありました。
でも、コードって“今の自分”だけじゃなくて“未来の自分”のために書くものなんですよね。
そこで今回は、私が実際に学びながら身につけた「読みやすくて効率的なコードの書き方」と「クラス命名のコツ」をまとめてみました。初心者さんでも今日から取り入れられる内容なので、気軽に読んでください
コードを書くときに意識していること
コードって、“短いほうが効率的”だと思われがちですよね。
でも本当の効率って、「あとから読んでもすぐ理解できるかどうか」だと思うんです。
私は以前、書いた本人しかわからないコードを書いてしまって、後から「どこを直せばいいのか」迷子になることがよくありました。それ以来、「動けばいい」より「読みやすい」を優先するようにしています。
たとえば、同じHTMLでもインデント（字下げ）が整っているだけで、ぐっと見やすくなるんです。
<!-- NG -->
<div><ul><li>Item</li><li>Item</li></ul></div>
<!-- OK -->
<div>
<ul>
<li>Item</li>
<li>Item</li>
</ul>
</div>
たったこれだけのことなんですが、視覚的に構造が分かりやすくなります。
私はVSCodeに「Prettier」という自動整形ツールを入れて、保存するたびに自動で整えるようにしています。
ちょっとしたことですが、これだけで“きれいに書けてる感”が出るし、精神的にもスッキリします。
コメントの入れ方のコツ
コメント（/* 〜 */）も、最初のうちは「全部に書いた方が丁寧なのかな？」と思っていたんですが、
実は書きすぎると逆に見づらくなるんですよね。
今は、セクションの区切りや大きなブロックの説明だけにコメントを入れるようにしています。
/* ========== Header ========== */
.header {
background: #fff;
}
小さなスタイルにはコメントを書かず、ブロック単位でまとめておくと、後から探すときも迷いません。「コメントを整理する」って、意外と大事です。
同じコードを何度も書かないようにするための工夫（リファクタリング）
初心者のうちは、「同じようなCSSをコピペして使いまわす」ということをやりがちだと思います。私もそうでした。
でも、同じプロパティを何度も書いていると、修正のときに地獄を見ます（笑）「この色変えたいのに、どこを直せばいいの！？」みたいな。
そんなときは、共通部分をまとめて一箇所で管理するのがポイントです。
/* NG */
.btn-blue { background: blue; color: #fff; }
.btn-red { background: red; color: #fff; }
/* OK */
.btn { color: #fff; padding: 10px 20px; }
.btn--blue { background: blue; }
.btn--red { background: red; }
こうしておくと、「ボタン全体の余白を変えたい」ときも.btnだけ直せばOK。ちょっとした構造の整理だけで、あとあとのちょっとした修正が何倍もラクになります。
クラス名をつけるときに意識していること
ここが一番悩むところですよね。私は最初、本当に適当につけていて、あとから「これ何のクラス？」ってなってました。
いま意識しているのは、「見た目ではなく、意味や役割でつける」ことです。
<!-- NG -->
<div class="red-box">エラーメッセージです</div>
<!-- OK -->
<div class="alert-box">エラーメッセージです</div>
red-boxは「赤い箱」という“見た目”の名前。でもデザインが変わって黄色になったら、もう意味が合わなくなります。
alert-boxなら「警告用のボックス」という“役割”を表しているので、色を変えても問題なし。この違いが、あとからの修正や拡張にすごく効いてきます。
私は実務で痛感したんですが、「急いでつけたクラス名ほど、後から自分の首を締める」んですよね（笑）なので、ちょっと面倒でも最初に丁寧につけるようにしています。
クラス命名のルールを統一する
クラス名って、本当に悩みどころですよね。私も最初のころは「英単語っぽければOKでしょ」ぐらいのノリでつけていました。でも後から見返してみると、「これ、何のためのクラスだっけ…？」ってなることが多くて。
コーディングを続けるうちに気づいたのは、書き方のルールを統一するだけでコードが一気に読みやすくなるということ。
どんなに中身が良くても、命名ルールがバラバラだとすごく読みにくいし、修正もしづらいんです。
クラス命名には大きく分けて、実は2つの方向性のルールがあります👇
1️⃣ 単語の書き方ルール（ケバブ・キャメル・スネーク）
2️⃣ 構造や役割を整理するルール（BEM・SMACSS）
この2つを混同してしまう人が多いんですが、実は“別ベクトル”の考え方なんです。最初にこの違いを理解しておくと、CSS設計がぐっと整いやすくなります。
ケバブケースがCSSの基本
まずは「単語の書き方」の話から。
CSSでは ケバブケース（kebab-case） という書き方が定番です。単語をハイフンでつなぐだけの、いちばんシンプルなルールです。
.main-title
.card-header
最初にこの名前を聞いたとき、私は「ケバブ？ 食べ物？」って思いました（笑）ハイフンが“串刺しのケバブ”に似ているからこの名前なんだそうです。
ケバブケースの良いところは、単語の区切りがひと目でわかること。
たとえば .main-title なら「メインタイトル」、.card-header なら「カードのヘッダー」。読みやすくて、すぐ意味がわかる。この「ひと目で理解できる」が本当に大事なんです。
一方で、CSS以外では他の書き方もあります。
| 名前 | 書き方 | よく使われる場面 |
|---|---|---|
| ケバブケース | .main-title | CSSでの王道 |
| キャメルケース | .mainTitle | JavaScriptでよく使う |
| スネークケース | .main_title | Pythonなどのプログラム言語 |
私は最初の頃、mainTitleとmain_titleを混ぜて使ってしまって、あとで「どっちだったっけ？」と混乱することがよくありました。（笑）
CSSでは ケバブケースで統一しておけば間違いなし。チーム開発でも「見た瞬間わかる」ので、コード全体に安心感が生まれます。
CSS設計を少しだけ意識してみる（BEMとSMACSS）
次に紹介したいのが、「構造」や「役割」を整理するためのルールです。ここで登場するのが BEM と SMACSS（スマックス）。この2つは、“クラス名の書き方”ではなく、CSS全体をどう整理するかという設計の考え方 です。
- BEM → パーツの中の構造を整理するルール
- SMACSS → CSS全体を役割ごとに整理するルール
ケバブケースが「言葉の並べ方」なら、BEMとSMACSSは「コードの組み立て方」を決めるルール、と考えるとわかりやすいです。
BEM（ベム）とは？
BEMは、「Block（部品）」「Element（その中の要素）」「Modifier（状態）」を組み合わせて命名する方法です。
<div class="card card--highlight">
<h2 class="card__title">タイトル</h2>
<p class="card__text">本文です。</p>
</div>
.card→ 部品そのもの（Block）.card__title→ 部品の中の要素（Element）.card--highlight→ 状態や見た目の違い（Modifier）
BEMのいいところは、どのパーツの、どの部分なのかが一目でわかること。クラス名を見るだけで、「あ、これはカードの中のタイトルだな」ってすぐに理解できます。
私も最初は「ひとりでやってるし、ここまでルールいらないか」と思ってたんですが、後でファイルを見返したときに「誰が書いたの？」って思うほどごちゃごちゃになってました（笑）
BEMを意識しはじめてから、整理されたCSSってこんなに気持ちいいのか！と感じたのを覚えています。
SMACSS（スマックス）とは？
SMACSS（スマックス）は、CSSを“役割ごと”に整理する考え方です。BEMが「クラス名のつけ方」なら、SMACSSは「CSS全体をどう整理するか」という感じ。
たとえば、CSSを書いていると、「このスタイルってどこに書くのが正解？」「レイアウトなのか、部品なのか…？」
って迷うことありませんか？私は実務でCSSが増えてきたときに、まさにそれで混乱してました。
SMACSSでは、それを防ぐためにスタイルを大きく5つのカテゴリに分けます👇
| カテゴリ | 内容 | プレフィックス例 |
|---|---|---|
| Base | 全体共通の基本スタイル（タグの初期設定など） | なし |
| Layout | ページの枠組み（ヘッダー・メイン・フッターなど） | .l-header |
| Module | ボタン・カードなどの部品 | .m-card, .m-btn |
| State | 状態を表すクラス（表示・非表示など） | .is-active, .is-hidden |
| Theme | カラーテーマなどのデザイン切り替え | .theme-dark |
たとえばこんな感じ👇
/* Layout */
.l-header {
background: #fff;
border-bottom: 1px solid #eee;
}
/* Module */
.m-card {
border: 1px solid #ddd;
padding: 1rem;
}
/* State */
.is-hidden {
display: none;
}
こうして「どのCSSがどんな役割を持ってるのか」を決めておくと、後から見返したときにすぐ目的のスタイルを探せます。
クラス名って、書いてるときは地味だけど、あとから効いてくるんですよね。
ケバブケースで統一して、BEMやSMACSSを少し意識するだけで、「どこに何を書いたっけ？」が減って、作業がすごくスムーズになります。結局のところ、命名ルールって“未来の自分が困らないための工夫”なんだと思います。
まとめ
効率的なコードを書くって、「速く書く」ことじゃないんですよね。むしろ「あとから直しやすい」「他の人が読んでもわかる」コードこそが本当に効率的な書き方です。インデントを整える、コメントを整理する、クラス名を意味でつける。
そんな小さな工夫の積み重ねが、後々の作業効率を大きく変えます。
私もまだまだ学びの途中ですが、日々のコーディングで「読みやすさ」を意識するようになってから、自分の成長を実感できるようになりました。これからコードを書くたびに、「未来の自分が読みやすいか」を意識してみてください。
きっと、少しずつ“整ったコード”が書けるようにるはずです。
コメント