MDN推奨JavaScriptコーディングガイド徹底解説｜React・TypeScript対応の最新ベストプラクティス

本記事には広告が含まれています

2025/05/07

MDN推奨JavaScriptコーディングガイド徹底解説｜React・TypeScript対応の最新ベストプラクティス

JavaScript は自由度が高く、個々の書き方が混在しやすい言語です。チーム開発ではスタイルの不一致がバグの温床になり、レビュー工数も膨らみます。

Mozilla が公開する JavaScript Sample Code Guide は、同社が社内のドキュメントやチュートリアル用に用いているコーディング規約を外部公開したものです。公式の絶対基準ではありませんが、実践的かつ網羅的に整理されているため、社内ガイドのたたき台として価値があります。

ここではこのガイドを軸に、最新ブラウザ環境・React 18・TypeScript 5 で役立つベストプラクティスを具体例付きで解説します。

配列初期化のベストプラクティス ― Array.from と new Array の使い分け

配列を生成するときは [] を第一選択とし、要素数のみが必要な場合に new Array(length) を検討します。全要素を同じ値で埋めるなら new Array(n).fill(0)、添字列を作るなら Array.from({length: n}, (_, i) => i) が明示的です。

Array.from() は fill() の二段階処理を避けられるため意図が読み取りやすく、未初期化スロットによる map()・forEach() の無視挙動を防げます。パフォーマンス差は現行エンジンでは誤差ですが、可読性とバグ予防の観点でリテラル優先が推奨されます。

参考：ECMAScript® 2023 Language Specification

コメントスタイル比較 ― MDNとGoogle Style Guideの差異

MDN は // 単行コメント 形式で文末に句点を打たない運用を提示しています。一方、Google JavaScript Style Guide は文として完結させるためピリオドを推奨します。

どちらを採用するかはプロジェクト方針次第ですが、統一が最優先です。複数行コメントは // を行頭に付けると差分表示が分かりやすく、/* … */ は引数の省略記号などコード自体の意味を示す場面に限定します。

説明よりも関数名・変数名で意図を表すことが長期保守では有効です。

関数宣言とアロー関数 ― 巻き上げを活かした読みやすい構造

再利用関数や React コンポーネントは関数宣言で定義し、巻き上げ（ホイスティング）を利用して主要ロジックをファイル先頭へ集約します。これにより呼び出し側と定義が近くなり、可視範囲が把握しやすくなります。

一方、コールバックにはアロー関数を採用し、暗黙の戻り値が単一式で完結する場合のみブレースを省略します。複数行や副作用がある場合は必ず波括弧を残し、可読性を優先しましょう。export 方針は「宣言時に即時 export」を推奨し、モジュール外公開の可否を一目で判別できるようにします。

反復処理 ― for…of を基準にし、副作用の制御を徹底

for...of は break・return・continue が使えるため柔軟性が高く、全要素の走査では第一候補に据えます。forEach() は関数スコープを終了できない点に注意し、ログ出力や DOM 操作など副作用限定の処理にとどめると意図が明確です。

インデックスが必要な場合は for...of で .entries() を使う方法（例：for (const [i, v] of arr.entries())）や、forEach((v, i) => { ... }) のように明示的な関数ブロックを用いる方法があります。

マッピングや絞り込みは map・filter など宣言的 API を選び、処理目的をコードに埋め込むことで検索性を高めましょう。

制御フローを浅く保つ ― 早期 return と統一ブレース

条件分岐が戻り値を決定する場合は早期 return で関数を抜け、else ブロックを省きます。これによりネストが一段浅くなり、視線移動が減少します。

また、単文でも if・for のブレースを省略しない方針を徹底すると、追記時のバグを防げます。switch 文では return と break を混在させず、値を返すロジックは return に統一してください。case 内で新たに変数を束縛する場合は波括弧で局所スコープを作り、副作用の漏れを防止します。

スコープと定数管理 ― const/let戦略と TAX_RATE 命名

変更予定のない識別子は const、再代入が不可避な場合のみ let を使い、var はレガシー互換に限定します。複数の変数を一行に並べず、一宣言一行 を守ると差分が明確になりレビュー効率が上がります。

例示として日本の消費税率を示すなら const TAX_RATE = 0.1; のように一般名詞を用いると、地域固有値である誤解を避けられます。プロジェクトが多言語・多地域に対応する可能性がある場合は JP_TAX_RATE などと地域接頭辞を加えるとより明確です。

TypeScript で as const を使うとリテラル型が固定化され便利ですが、再利用や拡張を見据える場合は汎用型に留める判断も必要です。

React 18とTypeScript 5への応用 ― Hooks, Suspense, as constの注意点

React 18 では関数コンポーネント＋Hooks が基本形です。useState や useEffect を呼び出す順序は条件分岐外に固定し、Hook Rules を ESLint で自動チェックします。

並列処理には Suspense と useTransition を組み合わせ、UI ブロッキングを防ぎます。型安全性を高める目的で as const によりリテラル型を固定する手法が流行していますが、プロパティ合成やマージが想定されるデータ構造に多用すると柔軟性を損ないます。

型を閉じるか開くかは、将来の要件変更と相談しながら決定してください。

参考：TypeScript Handbook – Literal Types & as const

ツールによる自動統制 ― ESLint・Prettier・CI設定サンプル

スタイルを人力で守るのは非効率です。eslint:recommended に @typescript-eslint と eslint-plugin-react を加え、MDN 準拠ルールを .eslintrc.js（CJS 環境なら .cjs も可）に定義します。

また、TypeScript を扱う場合は parser に @typescript-eslint/parser を指定することで、型情報を含む構文解析が有効になります。

例：

{
  "parser": "@typescript-eslint/parser",
  "extends": ["eslint:recommended", "plugin:@typescript-eslint/recommended", "plugin:react/recommended"],
  "rules": {
    "no-var": "error",
    "prefer-const": "error",
    "arrow-body-style": ["error", "as-needed"]
  }
}

Prettier とは役割を分離し、コードフォーマットのみを委任します。GitHub Actions で npm run lint を実行し、失敗時にマージをブロックすると合意違反の混入を防げます。

参考：ESLint 公式ドキュメント

モジュールシステムの選択 ― ES Modules vs CommonJS

ブラウザとモダンツールチェーン（Vite・Next.js など）は ES Modules を前提としています。Node.js でも type": "module" を package.json に設定すれば ESM がデフォルトで使え、import fs from "node:fs" のようにネイティブモジュールを読み込めます。

一方、既存の CJS エコシステムと混在する場合は拡張子 .cjs を使い分けると互換性を保てます。ESM への移行はツリ―シェイキングとブラウザキャッシュの効率を高め、ビルドサイズ削減に寄与します。