【実務向け】CSSのclass名の決め方(命名規則)はどうすればいいか?について解説

2019-09-13
Writing by Naoto

実務でリニューアル案件や改修(修正)案件をやっていると、他人が書いたコードをよく見ることになります。正直、悪い意味でヤバイと思うコードもたくさん目にします。笑

 

htmlよりcssのほうが、人によって書き方は様々だと感じます。htmlは色々な書き方があってOKというわけではなく、正しく意味付けするものなので、ちゃんと書いていれば人によってあまり差がないのは当然ですね。

 

僕は仕事をする上で効率的な書き方を自分なりに模索しながらやってきたため、結構自己流だったりもします。

 

案件によって最適な書き方は変わってきますが、自分の中で決まったルールを設けておいたほうが良いです。また、会社や案件によってはコーディング規約があり、細かなルールが決まっていることもあります。

 

今回はそんなルールの中でも重要な項目の1つである、cssclass名の決め方(命名規則)について紹介します。

TOPICS

css設計が大事な理由

正直、小・中規模案件くらいだと、それほど明確なcss設計をしなくても問題は起こりません。書き方によってサイトのパフォーマンスが変わるなんて話しもありますが、昨今のハイスペックなブラウザではその差はほんの誤差程度なのでその点も無視して良いでしょう。(もちろん小・中規模案件でもちゃんとcss設計するのがベストです。)

 

ただ、大規模案件になるとhtmlもcssもかなりの量になり、css設計がないと保守性が悪くなってしまったり、意図しないところに影響してしまったりします。また、複数人で制作する場合、css設計なしに各々が好き勝手に書くとコードがえらいことになります。

 

  • 予測しやすい
  • 再利用しやすい
  • 保守しやすい
  • 拡張しやすい

一般的にこの4つが良いcssの定義とされています。

 

どんな案件にも対応出来るように、cssの設計について学んでおくことは大切です。がっつり勉強したい方は下記の本がおすすめです。

 

idは使わない方がいい?

勉強を始めたばかりだとあまり聞かないかもしれませんが、idは使わない方が良いという意見があります。実際に僕が以前受けた案件のコーディング規約でも、idの使用を制限しているものもありました。また、有名な命名規則でもidは使いません。

 

使わない方が良いとされる、代表的な理由はこんなところでしょう。

  • 1ページに同じid名は1つだけしか使えず、再利用できない
  • classよりもidに書いたコードが優先されるので併用すると、優先度が複雑になる

 

基本はclassを使うことには、僕も同意です。使い回すことがなくてもclassで書きます。僕の場合は、大枠を囲うタグに対してと、ページ内リンクの飛び先になるタグにのみidをつけています。ただそこにcssを書くことはあまりないです。

 

 

<header id="header">
<!-- グロナビとかが入る -->
</header>

<div id="contact">
<!-- フォームとかが入る -->
</div>

<footer id="footer">
<!-- Copyrightとかが入る -->
</footer>

 

お問い合わせのページだと、大枠を囲うタグとは上の画像のような感じです。僕のidの使い方はほぼ下記の記事と同じでしたので、興味がある方は見てみてください。

マルチクラスとシングルクラス

命名規則の中でマルチクラスとシングルクラスという言葉が出てくるので、ここで解説しておきます。

 

マルチクラスとは1つの要素に対して、複数のclassを指定するものです。Bootstrapなんかはマルチクラスですね。後ほど紹介する、OOCSS、SMACSSもマルチクラスに分類されます。

 

<div class="col-md-4 text-muted bg-success"></div>

 

シングルクラスとは1つの要素に対して、1,2つ程度のclassを指定するものです。後ほど紹介する、BEMはシングルクラスに分類されます。

 

<div class="item"></div>

命名規則に関わらず守るべき事項

class名の命名規則には有名所で、BEM、OOCSS、SMACSSなどがあります。そのどれを使ったとしても、または独自の命名規則を採用するにしても、ここで紹介することは守ったほうが良いです。

日本語NG、全角NG、スペースNGなど超基本的なことは除いています。

要素名に対して装飾しない

p{
  text-align: center;
  font-size: 20px;
}

 

このように要素名に対してcssを書くと、全てのpタグにこの装飾が効いてしまいます。ある所では違う装飾をしたいと思ったら、それを打ち消すために要素名に対して書いたcssを上書きする必要があります。その結果、コードが複雑になり、コード量も多くなります。

 

例えばaタグの下線を消すなど、全てに共通で効かせたいものであれば良いのですが、そうではない場合は要素名に対して直接cssを書くのは辞めた方が良いでしょう。

 

もちろんリセットcssなどで使うのはOKです。

class名は意味のわかる英語にする

良い例

contact

main-copy

submit-btn

 

悪い例

otoiawase

aaa

btn1

 

『意味のわかる』=『セマンティックな』であり、セマンティックなclass名をつけましょう!と解説されてるサイトも多いです。

 

ローマ字や意味のわからない名前はやめましょう。書いてる時はよくても、後でコードをいじる際に分かりにくくなります。また、支障はなくてもカッコ悪いですよね。あーこれ作った人は適当な人だなとか、あまりスキルないんだなと思われてしまいます。

ハイフンとアンダースコアを統一する

良い例

main-copy

sub-copy

 

悪い例

main-copy

sub_copy

 

流石にこんな書き方をする方はあまりいないような気もしますが…

 

命名規則によっては1つのclassの中でハイフンとアンダースコアどちらも使うことがありますが、それぞれのルールは明確に決まっています。明確なルールなしに、ハイフンとアンダースコアを混同させるのは良くないです。

htmlに依存しない書き方をする

例えば下記のようなコードがあるとします。

 

.contact > div > div{ ... }

 

今は問題なくても、今後htmlの修正があった際にこの書き方だとcssも修正しないといけなくなる可能性があります。そのような書き方は避けるべきです。

命名規則ではないけどインデントや改行は統一する

統一感のある書き方をすることも大切です。とにかく綺麗に見やすく!

例えば下記のようなコードは汚くて良くないです。改修案件ではこんなコード良く見ます。笑

 

.kv-logo {
  width: 200px;
}
.kv-main-copy{
  font-size: 30px;
  font-weight: bold;
  color: #333333;
  margin-bottom: 20px;

}

.kv-sub-copy{
  font-size: 20px;
color: #666;
}

 

統一感を持って下記のようにすると良いでしょう。

 

.kv-logo{
  width: 200px;
}

.kv-main-copy{
  font-size: 30px;
  font-weight: bold;
  color: #333;
  margin-bottom: 20px;
}

.kv-sub-copy{
  font-size: 20px;
  color: #666;
}

 

インデントや改行は揃っていれば特に絶対こうしなくてはいけないといったことはないです。また、marginなどの余白も常に下につけるなど、自分でルールを決めておくことも大切です。

 

プロパティ名をアルファベット順にしている方もいますが、僕はそこまではしません。

代表的なclass名の命名規則

有名で良く使われている命名規則を紹介します。

独自の命名規則を採用している場合も、ここで紹介する3つの命名規則の考え方を一部採用したり、組み合わせていることが多い気がします。

BEM

BEMはBlock Element Modifierの略で、1番多く使われている命名規則だと思います。因みに僕も3つの中ではBEM推しです!

 

Block:大枠となる独立した要素

Element:Blockを構成する要素

Modifier:BlockやElementをスタイリングするもの

この3つに分けて、class名はBlock__Element–Modifierとします。ハイフンとアンダースコアは2つです。ハイフン1つの場合はElementとModifierの区切りではなく、ただの単語の区切りとして使います。

 

使用例

 

<div class="service">
  <div class="service__item">
    <h2 class="service__ttl">ここにタイトルが入る</h2>
    <p class="service__txt">テキストが入る。テキストが入る。テキストが入る。テキストが入る。テキストが入る。テキストが入る。テキストが入る。テキストが入る。テキストが入る。テキストが入る。</p>
    <a href="#" class="service__link service__link--red">MORE</a>
  </div>

  <div class="service__item">
    <h2 class="service__ttl">ここにタイトルが入る</h2>
    <p class="service__txt">テキストが入る。テキストが入る。テキストが入る。テキストが入る。テキストが入る。テキストが入る。テキストが入る。テキストが入る。テキストが入る。テキストが入る。</p>
    <a href="#" class="service__link service__link--yellow">MORE</a>
  </div>

  <div class="service__item">
    <h2 class="service__ttl">ここにタイトルが入る</h2>
    <p class="service__txt">テキストが入る。テキストが入る。テキストが入る。テキストが入る。テキストが入る。テキストが入る。テキストが入る。テキストが入る。テキストが入る。テキストが入る。</p>
    <a href="#" class="service__link service__link--green">MORE</a>
  </div>
</div>

 

基本的にページをまたいでの再利用しない前提なので、classの影響範囲の把握がしやすいです。従って、cssを修正したら、思わぬところにも影響したなんてことは起きません。ただやっぱり見た目が汚いですよね…。htmlはなるべくシンプルに、汚さず!がモットーなので気持ちは悪いですが、保守性なども考慮すると良いcss設計かなと思います。

 

OOCSS

OOCSSはObject Oriented CSSの略で、オブジェクト指向にもとづいたcss設計です。

Twitterや、Github、Youtubeなどで採用されているcss設計で、普段Bootstrapを使っている方は理解しやすいかもしれません。(BootstrapはTwitter社が開発したフレームワークです。)

 

開発者のNicole Sullivan氏は『レゴの集まりで考えよ』と言っています。レゴのパーツのようにガッチャンガッチャンとはめていくイメージです。

 

OOCSSでは

  • 構造(structure)と見た目(skin)
  • コンテナ(container)とコンテンツ(contents)

を分けて考えます。

 

使用例

<div class="nav-links">
  <a href="#" class="link link-blue">前の記事</a>
  <a href="#" class="link link-red">次の記事</a>
</div>

 

.link{
  width: 200px;
  height: 60px;
  line-height: 60px;
}

.bg-blue{ 
  background-color: #00f; 
  color: #fff; 
}

.bg-red{ 
  background-color: #f00; 
  color: #fff; 
}

 

構造:link

見た目:link-blue / link-red

コンテナ:nav-linksのついたdivタグ

コンテンツ:linkのついたaタグ

となっています。

コンテナとコンテンツの分離がわかりにくいので、補足すると。

 

コンテナとコンテンツを分離していないcssの書き方

.nav-links a{
  width: 200px;
  height: 60px;
  line-height: 60px;
}

 

コンテナとコンテンツを分離したcssの書き方

.link{
  width: 200px;
  height: 60px;
  line-height: 60px;
}

 

分離している方は使用する場所を限定されていないことがわかると思います。分離していない方はnav-linksの子要素に限定されてしまいます。OOCSSではこのように使用する場所を限定される書き方はNGです。場所を限定させないために、コンテナとコンテンツは分離します。

 

OOCSSは再利用性を意識した設計です。この考え方はコード量が少なくて済み、class名もシンプルで良いのですが、cssを変更した際にページをまたいで複数箇所に影響するので、その影響範囲を把握しにくくなります。

SMACSS

SMACSSはScalable and Modular Architecture for CSSの略で、OOCSSやBEMを参考に作られています。

 

Base:デフォルトスタイル。リセットcssなどもここに当たる

Layout:header ,footer などのページのレイアウト、接頭辞にはl-をつける。例) l-header

Module:レイアウトの構成要素であり、再利用可能なパーツ

State:特定の状態を示す、接頭辞にはis-をつける。例) is-active

Theme:サイトテーマ全体の外観を示す、接頭辞にはtheme-をつける。例) theme-color

この5つに分類されます。

 

OOCSSと同じように再利用性を意識した設計で、コード量が少なくて済み、class名もシンプルですが、影響範囲を把握しにくい問題はあります。

自己流でも明確なルールがあればOK

これは賛否両論あるかもしれませんが、自己流でも下記の3つを守っていれば良いかなと思います。実際、独自の命名規則を設けている会社もたくさんありますし。

  • 明確な命名規則である
  • 他人が見てもざっくり命名規則がわかる
  • 保守性を考えた命名規則

 

僕はOOCSS、SMACSSを使って上手いこと書ける気がしないです。笑

管理画面やwebサービスであればOOCSS、SMACSSでもうまくいく気がしますが、HPやLPなどのwebサイトでは影響範囲に関する問題が起こりそうです。(使ったことありませんが。)

 

命名規則をちゃんと意識するのは、基礎的なことがある程度出来てからでOKです。htm,cssの勉強中の方は、命名規則なんてものがあるんだと頭に入れておいて、いずれ勉強すれば良いと思います。

 

最後に効率的に書きたければ、絶対にSassも導入しましょう。この辺の話しはいつか別の記事で書こうと思います。

 

Twitterもやっているので、ぜひフォローしてください!!

Twitter(@naoto_k0401)