以前は一人でhtmlを組んでいたので好き放題にやってたんですが、私が入社した頃より時代は進み、社内体制も変わり、どうしたもんか…と悩んでいる時に道筋を付けてくれる書籍を紹介してもらいました。それが株式会社モノサス／コーディングファクトリーさんが出された「フロントエンド専門制作会社が教える早く正確なWeb制作のための実践的メソッド（以下「実践的メソッド」）」というタイトルだけで内容がわかる親切な専門書。
今回は書評ではなく、実践的メソッドを参考にネーミングルールを実践してみた…という内容です！
実践した内容
- CSSのモジュール化
- セレクタのネーミングルール
CSSのモジュール化ですが、以前は個人的に「なるべくプレーンなhtmlで装飾がされる」というのを目標にしてたんですが…固有のidで親子で装飾する方法はケースによっては便利なんですが、運用面でデメリットが多いと感じたのでモジュール化に方向転換を行いました。
※いわゆるOOCSS（参考：hijiriworld Web／オブジェクト指向CSSのススメ）ですが、頑なに「idを使わないぞ！オブジェクト指向だ！なんとしてもオブジェクト指向だ！」というのは些かidのレゾンデートルにも関わることですし、この先どうなるかもわからないので柔軟に対応していきます。
なのでモジュールやネーミングを他の案件と共有できれば、運用の際もスタッフが変わろうとも引き継ぎ直後のゴタゴタも少なく効率的！そして固有要素が少なくなるのでcssも短く出来る（ハズ）！つまりレスポンシブの際も効率化が図れる（ハズ）！良いことづくめ（のハズ）！
そこでネーミングルールの策定が重要となってきました。
というわけで本題です。
さっそくネーミングルールを決めよう
１）キャメルケースではなくスネークケースに
キャメルケースは複合語をひと綴りとして、要素語の最初を大文字で書き表す手法、スネークケースは アンダースコア（_）を区切記号として単語をつなげる手法です。
以前はキャメルケースを採用してたんですが、モジュール化する際は複合語が重要になってくるのでNG。そしてJavaScriptでは変数名にハイフンを使用するとマイナスとして認識されてしまうらしいので、結果的に全体の基礎ルールとしてスネークケースを採用しました。
２-a）ネーミングルールは「実践的メソッド」を基本とする
- 要素名は全て小文字
- スネークケースを採用
- idはユニーク部分のみに使用
- ネーミングは必要な部分のみ（headerやfooterなど、役割がはっきりしている要素にはidやclassは振らない）
概要はこんなところでしょうか。
２-b）ネーミングルールの詳細
役割 ＋ カテゴリ ＋ 連番（ ＋ 状態 ＋ デバイス）※カッコ内は状況により追加
こんな感じにしてみました。
実例
- .ttl_cmn_01…タイトル＋共通＋１
- .btn_submit_01…ボタン＋送信＋１
- .table_cmn_01…テーブル＋タイムテーブル＋１
- .list_cmn_01…リスト＋共通＋１
他にもimg（イメージ）、bnr（バナー）、txt（テキスト）などもこのルールに沿って設定していきます。ただ接頭の役割部分を細く設定しても元の木阿弥なので、あくまで基本形のみで展開させ、例外は最小とします。
なお、このルールは画像にも適応できますので連番を適応させない状態（役割 ＋ カテゴリ（ ＋ 状態 ＋ デバイス）※カッコ内は状況により追加）で設定します。
画像に連番を適応させてしまうと運営中に変更などで番号が抜けることが間々あり、そうなると連番の意味が失われてしまい、作業煩雑化の原因にもなります。なので多少面倒でも意味の通じるようなネーミングを行っていきます！
結果としてhtml〜css〜画像ファイル名と全体的に書式が統一され、整頓されたファイル構成となります。運用の面でもトラブルシュートもしやすく、追加のファイルや要素がある場合もネーミングに悩むことがなくなりました。
まとめ
モジュール化を進めることで例外の発生にも柔軟に対応できるようになったんですが、今までやっていたプレーンなhtmlで装飾がなされるガチガチ設定は完全にお払い箱か…というとそういうわけでもなく、Webに携わったことのない人がWordPressといったCMSで運用を行う場合、例外を認めない設定の方が良かったりします。
そこら辺はケースバイケースということで、オブジェクト指向じゃないから悪手だ…という考えに陥らないようにしないといけませんね。
ではまた。
