WebNAUT

もうページで分けない！　画像ファイルの命名規則

エンジニアK

Web開発を進める上で、ファイル名などの命名に悩む場面がたくさんあります。

命名規則決めを怠ってしまうと、追加・更新の際にいちいち悩むことになったり、
特に複数人で開発する場合に混乱が生じたりすることになります。

この記事では、画像ファイルの命名規則・フォルダ規則を提案します。
今回提案するファイル命名規則は、画像が使用されるページによって分類しません！

前提

当然のことながら、命名規則には絶対の正解があるわけではありません。
プロジェクトの性質によって、適切な管理方法は異なります。
ここで紹介する内容はあくまで一つの例として捉えていただき、
部分的に取り入れていただくのもよいと思います。

ただ、どのような命名規則であれ、プロジェクト内で統一されたルールが決めてあることが作業者間で共有できていることが重要です。

命名規則の例

軽く調べただけでも、画像の命名規則について様々な記事が見つかります。

これらの記事も参考にしつつ、プロジェクトを進める上で管理しやすいと思う命名規則を考えました。
特に、上記で紹介した記事ではどれも「ページ構造に合わせて命名する、もしくはフォルダを作る」方式でしたが、
今回提案するのは「使用するページで分けない」というルールです（理由については後述します）。

今回提案する命名規則

以上！

以下のようなディレクトリ構造になるイメージです。

(root)
├── index.html
├── ...
└── assets
    ├── css
    ├── js
    └── images
        ├── image_product-name_01_pc.jpg
        ├── image_product-name_01_sp.jpg
        └── ...

主要なルールとしてはこれだけですが、
なぜこういうルールにしたかなどの詳細を、これ以降で説明します。

ルール1：ファイル名にアルファベット大文字を使わない

大文字小文字が混在することによって、トラブルが起きる可能性があるからです。

例えば、 mv.jpg と MV.jpg というファイルを考えます。
これらを別々のファイルとして扱うか、同じとする（どちらかしか存在できない）かは、OSやサーバソフトなどの仕様や設定によって変わります。
ですので、
🙀「ローカル環境ではmv.jpgという指定でMV.jpgが読み込めていたのに、サーバーに上げたら読み込まなくなった！」
とか
🙀「サーバーにはmv.jpgとMV.jpgがそれぞれ別でアップロードされていたのに、ダウンロードしたら片方が上書きされた！」
といった問題が起こる可能性があります。

このような問題を避けるため、そもそも大文字を使わないことにしておくのが安全です。

ルール2:ファイル名は “カテゴリ[_名前][_連番][_状態].拡張子” の形式

の4種類を、_（アンダースコア）で連結します。
名前、連番、状態の3種類は必要に応じて省略可能です。

具体的には以下のようなファイル名ができあがります。

カテゴリと名前のような区切りは_（アンダースコア）を使い、
複数単語からなる場合の単語区切りには-（ハイフン）を使います。

（補足）アンダースコアとハイフンの使い分け

CSSの命名規則として有名なMindBEMdingと近いルールになることから、
複数単語の区切りに-（ハイフン）を使用するルールとしました。

MindBEMding： MindBEMding – getting your head ’round BEM syntax – CSS Wizardry – Web Performance Optimisation

一方で、多くのエディタではテキストをダブルクリックした際、_（アンダースコア）つなぎは1つのワードとしてまとめて選択される仕様がありますが、
-（ハイフン）つなぎは別々の単語として扱われてしまいます。
この挙動を踏まえると、icon-open_in_new-black.svgのように、セクション区切りを-（ハイフン）、単語区切りを_（アンダースコア）とするほうが、”black”だけを変更するときなどに便利です。

今回提案するルールとしては、普段MindBEMdingの書き方に慣れている方が導入しやすいことも考え、単語区切りを-（ハイフン）つなぎとしていますが、
ダブルクリックによるテキスト選択の挙動を重視する場合、逆の使い方（セクション区切りを-（ハイフン）、単語区切りを_（アンダースコア））としていただくのもよいと思います。

カテゴリ

ファイル名を見て、ある程度想定用途がわかるようにカテゴリを頭につけます。
また、名前順に並べたとき、同じカテゴリの画像がまとまることで目的の画像が探しやすくなります。

mv

サイトのメインビジュアル。
Webサイトでは必ずと言っていいほど登場するため、専用のカテゴリとしています。

ちなみに、日本ではメインビジュアル（またはキービジュアル）と呼ぶことが多いですが、英語圏では hero image と呼ぶのが一般的のようです。
Hero image – Wikipedia

英語の正しさとしてはheroかもしれないですが、日本でのわかりやすさ的にmvでよいと思っています。
ただし、欧米圏をメイン対象に作るサイトではheroを使うようにしています。

figure

グラフ、組織図、地図などの図版。
単なる絵としての画像ではなく、数字や文字などの情報を含む画像として区別しています。

bg

背景として使用する画像。

icon

アイコン。

logo

企業ロゴ・サービスロゴなど。加工しない画像。

banner

リンクとして使用される画像。
単体でボタンの役割を持つものです。

text

特殊なフォントを使っていたり、装飾などの加工をしていて、画像化したテキスト。
altには書かれている文字を反映する必要があります。

favicon

ファビコン。

ogp

OGP画像。

image

上記以外の画像全般。

名前

画像の内容を表す名前をつけます。
複数単語からなる名前はハイフンでつなぎます。

名前が決めにくい場合は、名前をつけずに連番のみを使うのもアリです。

連番

2桁で0パディングをつける、 01 の形式としています。
一つのカテゴリ_名前で登場するのは多くても数十件、と想定しています。

状態

PC/SPの出し分け、色のバリエーション、サイズの違いなど、内容としては同じだが違う画像ファイルのもの。
CSS命名規則のBEMでいうところの、modifierです。
ファイル名の末尾に設定することで、ファイルを名前順に並べたとき、状態違いの画像が同じ場所に並びわかりやすくなります。

ルール3：英単語を省略しない

前述のファイル名を決める際に適用される内容です。
名前をつけるときは、英単語の省略（title→ttl など）をしないことにしています。

理由1：意味を読み取りやすくするため

(title→ttlはよく使用されるのでわかるとはいえ、）ttlだけ見るとturtle🐢の略ともとれてしまいます。
独自の略し方をしてしまうと、別の人が見た時に何を表しているかわかりにくくなります。

理由2：ファイル名を書く際に迷わないため

どう略すのか、そもそも略すのか略さないのかを判断するのが大変になります。
detailを略すとなったら、dtlにするのか、detにするのか、はたまた略さないのか……。
都度判断すること、そしてそれをチーム全体で共有するのは大変です。

理由3：スペルチェッカーを機能させるため

私はVSCodeで「Code Spell Checker」という拡張機能を使用して、スペルミスには青波線が引かれるようにしています。
titleをtitelのように打ち間違えると、青波線が引かれ、パッとわかります。
省略形を使ってしまうと、正しい英単語ではないため、スペルミス判定されてしまいます。
もちろん、単語リストに追加する方法はありますが、いちいち登録するのは面倒なので最初から正しい英単語にしておくのが楽です。

省略する場合

省略するのは10文字以上のときとし、省略パターンはREADME等に記載することにします。
カテゴリで使用したmv, bgは
main visual、backgroundと10文字以上であり、
カテゴリ名としてあらかじめ定義しているため使用します。

ルール4：複数単語は必ず区切る

maintitleのように、複数単語をそのままつなげてしまうと、単語の区切りがわかりにくくなる他、前述のスペルチェッカーでスペルミス判定されてしまうため、
main-titleのように、必ずハイフンで区切るようにします。

ルール5：画像ディレクトリ名は “images”

imgでもなく、imageでもなく、imagesにします。

これは実用上の意味はあまりなく、好みの問題ですが、
（特に英語圏で？）一般的なのがimagesのようです。

WordPressのディレクトリも

/wp-admin/images

Drupalのコアテーマのディレクトリも

/core/themes/bartik/images

Googleも（検索ページのロゴ）

https://www.google.com/images/branding/googlelogo/1x/googlelogo_color_272x92dp.png

Appleも（Apple Watchのロゴ）

https://www.apple.com/jp/home/heroes/good-wrist/images/hero_logo_why_apple_watch_large.png

どれもimagesでした。

imgにしないの？

前述の通り、英単語は基本的に省略すべきでないという理由です。

imgじゃなくてimagesなら、cssはstylesheetsにしないの？

css, jsは拡張子基準のディレクトリ名という認識なので、別で考えて問題ないと思います。
画像はjpgもpngもあるので総称してimagesが適切だと思います。
HTMLのimgタグは存在しますが、必ずしもimgタグに入るわけでもないですし（background-imageなど）。

ルール6：ページごとのフォルダ分けをしない

OOCSSといったCSSの設計思想で「構造と見た目を分離する( https://github.com/stubbornella/oocss/wiki#separate-structure-and-skin )」ようにしているのと近い考えです。
画像ファイルについても、ページ構造（HTML）に依存しないようにするのがよい、という考え方です。

assets/imagesディレクトリに、画像をどかっと放り込みます。

ページ名のディレクトリは作らないですし、ページ名の接頭辞もつけません。

理由1：画像の使用場所が変わっても、画像パスを変えないため

これがメインの理由です。

Web制作は一度作ったらそれっきりということはなかなかなく、更新や改修がつきものですので、
画像を使用するページが変わるといったことがたびたび発生します。

例えば仮にページごとのフォルダを作るとして、
トップページで使う画像を/images/top、
サイト共通で使う画像を/images/commonに入れるとします。

これまでトップページで使用していた
/images/top/image_01.jpg
を別のページにも使うとなった場合、このファイルを
/images/common/images_01.jpg
に移動する必要が出てきます。
となると、既存のトップページのHTMLに記述している/images/top/image_01.jpgの指定も含めて書き換える必要が発生してしまいます。🙀

このように、ページ（HTML）の構造に合わせた命名にしていると、必要以上の変更作業が発生することになってしまいます。
ページ構造と命名を独立させることでこれが解消できます！

理由2:画像の一覧確認をしやすくするため

サイト内で使用している画像を全てチェックしたい、という状況は何かにつけて発生します。
一つのフォルダの直下にまとまっていれば、このフォルダだけ見ればよいことになり確認しやすくなります。

理由3:ファイル名を一意にするため

これも結構重要です。
もしディレクトリを分けてしまうと、
/top/image_01.jpg
/about/image_01.jpg
のように、同じ名前の別ファイルが発生する可能性があります。

これでは、

🧑‍💼「image_01.jpg変更して！」
🤔「どこの？」
とか、

👨‍💻（image_01.jpgの使用箇所を検索）
🤔「topとaboutどっちだ！？」
とか、

🙀「/top/image_01.jpgと/about/image_01.jpgのファイルだけ渡したいけど、わざわざ別のフォルダに入れなきゃいけない！」

といった問題が起こります。

一つのディレクトリにまとめることで、必然的にファイル名が一意な名前（それぞれ異なる名前）になります。
それにより上記の問題は解決でき、

✅ 「image_01.jpg」といったら一つだけ！
✅ 「image_01.jpg」で検索すれば対象のパスだけが見つかる！
✅ 一部の画像を渡したいときも、一つのフォルダに入れられる！

このように同じフォルダに入れることで管理・コミュニケーションがスムーズになります！ 👏

まとめ

画像ファイルの命名ルールを適切に決めておくことで、運用しやすい画像ファイル管理ができます。
ファイル命名規則に迷ったら上記のルールを使ってみてください。

なお、冒頭でも述べましたが、これらはあくまで一つの方法です。
今回はページ構造でフォルダを分けないことを提案しましたが、当然プロジェクトによっては分けた方がよい場合もあります。
この設計を元に、プロジェクトの状況に合わせてカスタマイズするのもよいですね。
プロジェクトメンバー間でルールが共有できている・運用できることが大切です！