チームでWeb制作を行う際、メンバーごとにコードの書き方がバラバラだと、保守や修正のたびに「このクラス名は何を意味しているのか」「インデントはスペースとタブのどちらを使っているのか」と確認作業に時間を取られます。
コーディング規約とは、コードの書き方に関する統一ルールのことで、命名規則・インデント・コメントの書き方・ファイル構成などを定めたものです。規約があることで、誰が書いても読みやすく、修正しやすいコードベースを維持できます。
この記事では、HTML・CSS・JavaScriptそれぞれのコーディング規約の作り方と、実務で役立つ具体的なルールを解説します。個人制作でも規約を意識しておくと、コードの品質が格段に上がります。
コーディング規約はなぜ必要か
規約がもたらすメリット
- 可読性の向上：統一されたルールで書かれたコードは、初めて見る人でも構造と意図をすぐに理解できる
- 保守性の向上：修正箇所を特定しやすくなり、バグの発生リスクが低下する
- オンボーディングの効率化：新しいメンバーがプロジェクトに参加した際、規約を読むだけでコードの書き方が把握できる
- レビューの効率化：コードレビュー時にスタイルの指摘が減り、ロジックや設計の議論に集中できる
参考になる既存の規約
ゼロから規約を作るのは大変なので、まずは既存の規約を参考にするのがおすすめです。
- Google HTML/CSS Style Guide：Googleが公開しているHTML/CSSのコーディングガイドライン
- Airbnb JavaScript Style Guide：JavaScriptの命名規則やコーディングスタイルを詳細に定めた規約
- WordPress Coding Standards：WordPress開発向けのコーディング標準
HTMLのコーディング規約
ドキュメント構造
HTMLの基本的な規約として、以下のルールを定めておきましょう。
- DOCTYPE宣言は
<!DOCTYPE html>を使用する（HTML5） - lang属性を指定する（
<html lang="ja">） - 文字エンコーディングはUTF-8を指定する（
<meta charset="UTF-8">） - viewportのmetaタグを記述する
セマンティックなマークアップ
HTMLタグは「見た目」ではなく「意味」に基づいて選択するのが原則です。見出しには<h1>〜<h6>、段落には<p>、リストには<ul>/<ol>、ナビゲーションには<nav>、記事コンテンツには<article>を使います。
- 見た目を太字にしたいだけの場合は
<b>ではなくCSSで対応する - ブロック要素の汎用コンテナには
<div>、インライン要素には<span>を使う。ただし、適切なセマンティックタグがある場合はそちらを優先する - 画像には必ずalt属性を設定する。装飾目的の画像は
alt=""（空文字）とする
インデントと改行
インデントはスペース2個またはスペース4個に統一します（チームで1つに決める）。ネストされた要素は1段階インデントし、コードの階層構造を視覚的に表現します。
エディタの設定で「タブをスペースに変換」をオンにしておくと、環境による表示の違いを防げます。VS Codeでは「Editor: Tab Size」と「Editor: Insert Spaces」の設定を確認しましょう。
CSSのコーディング規約
命名規則
CSS設計において最も重要なのが、クラス名の命名規則です。代表的な命名規約を紹介します。
BEM（Block Element Modifier）は、最も広く使われているCSS命名規則です。
- Block：独立した意味のあるコンポーネント。例：
.card - Element：ブロックの構成要素。アンダースコア2つで接続。例：
.card__title - Modifier：状態やバリエーション。ハイフン2つで接続。例：
.card--featured
BEMの最大のメリットは、クラス名を見るだけで「何のコンポーネントの、どの部分で、どんな状態か」がわかることです。
プロパティの記述順序
CSSプロパティの記述順序を統一することで、コードの一貫性が向上します。一般的には以下の順序が推奨されます。
- レイアウト：display、position、top/right/bottom/left、z-index
- ボックスモデル：width、height、margin、padding、border
- タイポグラフィ：font-family、font-size、line-height、color
- ビジュアル：background、box-shadow、border-radius、opacity
- その他：transition、animation、cursor
避けるべき書き方
- IDセレクタの使用：詳細度が高すぎてスタイルの上書きが困難になる。クラスセレクタを使う
- !importantの乱用：スタイルの優先度管理が破綻する原因になる。詳細度の設計で解決する
- タグセレクタの直接指定：
divやpに直接スタイルを当てると、意図しない箇所に影響が及ぶ - マジックナンバー：
margin-top: 37px;のような根拠不明な数値。変数やデザイントークンで管理する
CSS設計手法
BEM以外にも、以下のCSS設計手法があります。プロジェクトの規模やチームの特性に合わせて選択しましょう。
- FLOCSS：Foundation・Layout・Object（Component/Project/Utility）の3層構造。日本のWeb制作現場で人気がある
- ITCSS：詳細度の低い順にCSSを配置する設計。大規模プロジェクト向け
- ユーティリティファースト（Tailwind CSS）：ユーティリティクラスを組み合わせてスタイリングする。コンポーネント指向のフレームワークと相性が良い
JavaScriptのコーディング規約
命名規則
JavaScriptでは、以下の命名規則が一般的です。
- 変数・関数：camelCase（例：
userName、getUserName()） - 定数：UPPER_SNAKE_CASE（例：
MAX_RETRY_COUNT） - クラス：PascalCase（例：
UserAccount） - プライベートプロパティ：先頭にアンダースコア（例：
_internalValue）
変数名や関数名は省略せず、意味が伝わる完全な単語を使うのが原則です。btnではなくbutton、usrではなくuserと書きます。
変数宣言
varは使わず、const（再代入しない値）とlet（再代入する値）を使い分けます。基本的にconstを優先し、再代入が必要な場合のみletを使います。
関数の書き方
- 1つの関数は1つの責務に限定する（単一責任の原則）
- 引数が多すぎる関数はオブジェクトで受け取ることを検討する
- 関数の行数は30行以内を目安にする。長くなる場合は分割を検討する
コメントの書き方
コメントは「なぜそのコードを書いたのか（Why）」を説明するために使います。「何をしているか（What）」はコード自体で表現し、コメントで補足する必要がないように書くのが理想です。
コメントアウトしたコードを残しておくのは避けましょう。「後で使うかもしれない」と思って残したコードが、時間が経つにつれて意味不明になり、コードベースを汚す原因になります。バージョン管理（Git）を使っていれば、過去のコードはいつでも復元できます。
ツールによる規約の自動化
規約を人間の目だけでチェックするのは限界があります。ツールを活用して自動チェック・自動修正する仕組みを導入しましょう。
代表的なツール
- Prettier：コードフォーマッター。インデント・改行・セミコロンなどを自動で統一する
- ESLint：JavaScriptのリンター。命名規則やベストプラクティスへの違反を検出する
- Stylelint：CSSのリンター。プロパティの記述順序やクラス名の命名規則をチェックする
- HTMLHint：HTMLの構文チェッカー。不正なマークアップを検出する
VS Codeでは「保存時に自動フォーマット」の設定を有効にしておくと、コードを保存するたびにPrettierが自動で整形してくれます。設定一つでコーディングスタイルの統一が保証されるため、導入効果は非常に高いです。
EditorConfigの活用
プロジェクトのルートディレクトリに.editorconfigファイルを置くと、エディタの設定（インデントの種類・サイズ、文字コード、改行コード）をチーム全体で共有できます。エディタの種類（VS Code、WebStorm、Sublime Textなど）に依存しないのが利点です。
よくある質問（Q&A）
Q：個人制作でもコーディング規約は必要ですか？
A：必要です。半年後、1年後に自分のコードを修正するとき、規約に沿って書かれたコードはスムーズに理解できます。また、ポートフォリオとしてコードを公開する場合、規約に沿った統一感のあるコードは技術力のアピールにもなります。
Q：規約はどのくらい厳密に決めるべきですか？
A：最初は最小限のルール（命名規則・インデント・ファイル構成）から始め、開発を進めながら必要に応じてルールを追加していくのが現実的です。最初から細かく決めすぎると、ルールを守ること自体が負担になります。
Q：既存のプロジェクトにコーディング規約を導入するにはどうすればいいですか？
A：一度にすべてのコードを書き直すのは非現実的です。新しく書くコードや修正するコードから段階的に規約を適用していく方法が推奨されます。Prettierを導入して、まずフォーマットだけ統一するのが最初のステップとして効果的です。
Q：BEMのクラス名が長くなりすぎるのが気になります。
A：BEMのクラス名が長くなるのは「仕様」であり、可読性とのトレードオフです。ネストが深くなりすぎる場合は、Elementを独立したBlockとして切り出す（コンポーネントの分割）ことで改善できます。
Q：SassやLessなどのプリプロセッサを使う場合、規約は変わりますか？
A：基本的な命名規則やプロパティの記述順序は同じです。プリプロセッサ固有のルールとして、ネストの深さ（3階層まで）、変数やミックスインの命名規則、ファイル分割のルールなどを追加で定めておくと良いでしょう。
まとめ
コーディング規約は「チームのためのルール」であると同時に「未来の自分のためのルール」です。HTML・CSS・JavaScriptそれぞれの命名規則・インデント・記述順序を統一し、PrettierやESLintなどのツールで自動化することで、コードの品質と開発効率を大幅に向上させられます。
まずはGoogleやAirbnbの規約を参考にして最低限のルールを決め、PrettierとEditorConfigを導入するところから始めてみてください。ツールによる自動化を最初にセットアップしておけば、規約を「意識して守る」必要がなくなり、自然と統一感のあるコードが書けるようになります。
