JavaScriptコードフォーマット：ツールと標準規約

プルリクエストを開いたら差分の半分が空白の変更だった——そんな経験をすれば、問題の深刻さはすぐに分かるはずです。フォーマットの不統一は時間を浪費し、コードレビューを煩雑にし、ロジックとは無関係なマージコンフリクトを引き起こします。解決策はシンプルです。フォーマットの標準を決め、自動化し、二度と悩まないようにすること。

本記事では、JavaScriptのフォーマットを「解決済みの問題」にするためのツールと標準規約を紹介します。

なぜ統一されたフォーマットが重要なのか

フォーマットは見た目の問題ではありません——チームの開発速度に直結する問題です。開発者ごとにインデント、括弧の位置、行の長さが異なると、次の3つの問題が発生します。

コードレビューが遅くなる。 レビュアーはロジックの評価ではなく、見慣れないフォーマットの解読に頭を使うことになります。コードベースの他の部分と見た目が異なる関数は、本質とは違う理由で注目を集めてしまいます。

マージコンフリクトが増える。 開発者Aがタブでファイルを整形し、開発者Bがスペースを使えば、Gitはすべての行が変更されたと表示します。本来の3行のバグ修正は差分に埋もれてしまいます。

認知負荷が増大する。 スタイルの異なるファイルを行き来するたびに、脳は構造を再解析しなければなりません。統一されたフォーマットなら、散文を読むようにコードを読めます——目が自然にどこを見ればよいか分かるのです。

解決策は「どのスタイルが一番良いか」を議論することではありません。一つを選び、自動化することです。

主要なJavaScriptスタイルガイド

ツールを選ぶ前に、JavaScriptのフォーマット慣習を形作ってきた主要なスタイルガイドを理解しておくと役立ちます。

Airbnb Style Guide

最も広く採用されているJavaScriptスタイルガイドです。セミコロンの使用を必須とし、シングルクォートを推奨し、複数行の構文では末尾カンマを必須とし、2スペースインデントを使用します。ESLint設定（eslint-config-airbnb）には、フォーマットとコード品質の両方をカバーする数百のルールが含まれています。

// Airbnb style
const getUserData = (userId) => {
  const user = findUser(userId);
  return {
    name: user.name,
    email: user.email,
  };
};

Standard Style

セミコロンに関しては正反対のアプローチをとります——セミコロンは一切使いません。2スペースインデントとシングルクォートを使用します。standardパッケージには独自のリンターが含まれているため、別途ESLintの設定は不要です。

// Standard style
const getUserData = (userId) => {
  const user = findUser(userId)
  return {
    name: user.name,
    email: user.email
  }
}

Google Style Guide

Airbnbと似ていますが、JSDocの要件や命名規則にいくつかの違いがあります。2スペースインデントを使用し、セミコロンを必須とし、シングルクォートを推奨します。

これらのスタイルガイドにはそれぞれ長所と短所があります。重要なのはどれを選ぶかではなく、一貫性を保つことです。そして最近では、Prettierに任せることで議論そのものを省略するチームが増えています。

Prettier：独自の主張を持つフォーマッター

Prettierは、ほとんどの判断を不要にすることでJavaScriptのフォーマットを変革しました。コードをAST（抽象構文木）にパースし、独自のルールに従って再出力します。個々のフォーマット設定を細かく調整するのではなく、いくつかの高レベルオプションを設定するだけで、あとはPrettierが処理してくれます。

インストール

npm install --save-dev prettier

.prettierrc設定ファイルを作成します：

{
  "printWidth": 80,
  "tabWidth": 2,
  "useTabs": false,
  "semi": true,
  "singleQuote": true,
  "trailingComma": "all",
  "bracketSpacing": true,
  "arrowParens": "always"
}

主要な設定オプション

printWidth（デフォルト：80） — Prettierがコードを折り返す行の長さです。これは厳密な制限ではなく、式を複数行に分割するタイミングのガイドラインとして使われます。ワイドモニターを使うチームでは100や120に設定するのが一般的です。

semi（デフォルト：true） — 文の末尾にセミコロンを付けるかどうかです。Standard Styleを好む場合はfalseに設定します。

singleQuote（デフォルト：false） — ダブルクォートの代わりにシングルクォートを使用します。ほとんどのJavaScript開発者はシングルクォートを好むため、trueの方が一般的な設定です。

trailingComma（デフォルト："all"） — 有効な箇所すべてに末尾カンマを付けます。リストに新しい項目を追加したとき、変更行が2行ではなく1行だけになるため、よりクリーンなGit差分が得られます。

// 末尾カンマなし — "d"を追加すると2行が変更される
const items = [
-  "a",
-  "b",
-  "c"
+  "a",
+  "b",
+  "c",
+  "d"
];

// 末尾カンマあり — "d"を追加すると1行だけ変更される
const items = [
  "a",
  "b",
  "c",
+  "d",
];

arrowParens（デフォルト："always"） — アロー関数の単一パラメータを括弧で囲むかどうかです。"always"は(x) => x、"avoid"はx => xになります。

Prettierの実行

# すべてのファイルをフォーマット
npx prettier --write .

# 変更せずにチェックのみ
npx prettier --check .

# 特定のファイルタイプをフォーマット
npx prettier --write "src/**/*.{js,jsx,ts,tsx}"

生成されたファイルをスキップするために.prettierignoreファイルを追加します：

node_modules
dist
build
coverage
*.min.js

圧縮されたJavaScriptを扱う場合は、Code Minifierが適切に圧縮を処理します——圧縮されたコードを手動で編集するのはやめましょう。

ESLint：フォーマットを超えて

ESLintはPrettierとは異なる目的を持っています。Prettierがコードの「見た目」を扱うのに対し、ESLintはコードの「振る舞い」を検査します。ESLintのルールは2つのカテゴリに分かれます：

フォーマットルール — インデント、スペース、括弧の配置など。これらはPrettierと重複するため、両方を使う場合は一般的に無効にすべきです。

コード品質ルール — 未使用変数、到達不能コード、暗黙の型変換、エラー処理の欠如など。ESLintが真価を発揮するのはこちらです。

推奨セットアップ

npm install --save-dev eslint @eslint/js

最小限のeslint.config.js：

import js from '@eslint/js';

export default [
  js.configs.recommended,
  {
    rules: {
      'no-unused-vars': 'warn',
      'no-console': 'warn',
      'eqeqeq': 'error',
      'no-implicit-coercion': 'error',
    },
  },
];

TypeScriptプロジェクトの場合はtypescript-eslintを追加します：

npm install --save-dev typescript-eslint

import js from '@eslint/js';
import tseslint from 'typescript-eslint';

export default tseslint.config(
  js.configs.recommended,
  ...tseslint.configs.recommended,
);

Prettier + ESLintの連携

両方のツールを調整なしに実行すると競合が生じます——ESLintのフォーマットルールがPrettierの出力と衝突するのです。解決策はeslint-config-prettierで、Prettierと競合するすべてのESLintルールを無効化してくれます。

npm install --save-dev eslint-config-prettier

import js from '@eslint/js';
import prettierConfig from 'eslint-config-prettier';

export default [
  js.configs.recommended,
  prettierConfig,
  {
    rules: {
      // コード品質ルールのみここに記述
      'no-unused-vars': 'warn',
      'eqeqeq': 'error',
    },
  },
];

このセットアップにより、フォーマットはPrettierが、コード品質はESLintがそれぞれ担当します。競合もなく、混乱もありません。

EditorConfigによるエディタ間の一貫性

チームの全員が同じエディタを使っているとは限りません。EditorConfigは、VS Code、WebStorm、Vim、Sublime Textなど、ほとんどのエディタで動作するベースラインを提供します。

プロジェクトルートに.editorconfigファイルを作成します：

root = true

[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[*.md]
trim_trailing_whitespace = false

EditorConfigはインデント、改行コード、末尾空白といった基本事項を、Prettierが実行される前に処理します。これにより、Windowsの開発者がUnixベースのプロジェクトに\r\nの改行コードを持ち込むという、よくある問題を防げます。

HuskyとWSlint-stagedによるGitフック

自動フォーマットは実際に実行されなければ意味がありません。コミットのたびにnpx prettier --writeを実行するのを開発者の記憶に頼るのは、スケールしません。Gitフックがこの問題を解決します。

セットアップ

npm install --save-dev husky lint-staged
npx husky init

package.jsonに追加します：

{
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "prettier --write",
      "eslint --fix"
    ],
    "*.{json,md,css}": [
      "prettier --write"
    ]
  }
}

Huskyのpre-commitフック（.husky/pre-commit）を更新します：

npx lint-staged

これにより、コミットごとにステージされたファイルの自動フォーマットとESLintの修正が実行されます。開発者はフォーマットのことを考える必要がなくなります——すべて自動で処理されるのです。

これがチームプロジェクトにおけるゴールドスタンダードです。Prettierがフォーマットし、ESLintがバグを検出し、Huskyがコミットごとに両方を強制します。

セミコロン論争

JavaScriptのフォーマットを語る上で、セミコロンの問題は避けて通れません。実用的な答えを述べると、チーム内で統一されていればどちらでも構いません。

セミコロン賛成派： 明示的な文の終端により、ASI（自動セミコロン挿入）のエッジケースを回避できます。AirbnbとGoogleのスタイルガイドはセミコロンを必須としています。

セミコロン不要派： JavaScriptのASIが自動的に終端を処理します。視覚的なノイズが減り、コードがすっきりします。Standard Style Guideはセミコロンを省略しています。

よく警告されるASIの落とし穴——(や[で始まる行の問題——は、ESLintのno-unexpected-multilineルールで検出できます。実際には、適切なリンティングと組み合わせれば、セミコロンなしでも完全に安全です。

一つを選び、Prettierのsemiオプションを設定して、次に進みましょう。Prettierがどちらの場合でも一貫して追加または削除してくれます。

JavaScriptにおけるタブ vs スペース

JavaScriptのエコシステムでは圧倒的にスペースが使われています——具体的には2スペースインデントです。これは普遍的なルールではありませんが（Goはタブ、Pythonは4スペースを使用）、JavaScriptにおいては強い慣例です。

なぜ2スペースなのか？ JavaScriptのネストされたコールバックパターンやチェーンメソッドは、インデントを素早く深くします。2スペースなら、深くネストされたコードも画面の右端に押し出されることなく読みやすさを保てます。

なぜタブではないのか？ タブは各開発者が表示幅を自由に設定できるため一見便利に思えますが、エディタ間でコードの位置揃えが崩れることがあります。スペースなら、自分が見ているものと全員が見ているものが同じです。

Prettier（tabWidth: 2, useTabs: false）とEditorConfig（indent_style = space, indent_size = 2）で一度設定すれば、それで決着です。

よくあるフォーマットの落とし穴

アロー関数の不統一

// 不統一 — これは避けましょう
const double = x => x * 2;
const add = (a, b) => a + b;
const greet = (name) => {
  return `Hello, ${name}`;
};

// 統一 — PrettierでarrowParens: "always"を使用
const double = (x) => x * 2;
const add = (a, b) => a + b;
const greet = (name) => {
  return `Hello, ${name}`;
};

オブジェクト分割代入のスタイル

// 詰まっている — 読みにくい
const {name,email,role} = user;

// 整形済み — Prettierが自動的に処理
const { name, email, role } = user;

// プロパティが多い場合は複数行に
const {
  name,
  email,
  role,
  department,
  startDate,
} = user;

import文の整理

Prettierはimportの並べ替えを行いません——それはフォーマットではなくコード品質の問題です。eslint-plugin-importやsimple-import-sortプラグインを使いましょう：

// 整理されたimport
import React from 'react';
import { useState, useEffect } from 'react';

import { Button } from '@/components/Button';
import { Modal } from '@/components/Modal';

import { formatDate } from '../utils/dates';
import { validateEmail } from '../utils/validation';

長い三項演算子

// 1行では読みにくい
const label = isAdmin ? 'Admin Dashboard' : hasEditPermission ? 'Editor View' : 'Read Only';

// Prettierが読みやすい複数行に再整形
const label = isAdmin
  ? 'Admin Dashboard'
  : hasEditPermission
    ? 'Editor View'
    : 'Read Only';

新規プロジェクトのセットアップ

新しいJavaScriptまたはTypeScriptプロジェクトの完全なセットアップチェックリストです：

依存パッケージのインストール：

npm install --save-dev prettier eslint eslint-config-prettier husky lint-staged

.prettierrcを作成 — チームの好みに合わせた設定を記述
.editorconfigを作成 — エディタ間のベースラインを設定
ESLintを設定 — コード品質ルールのみ（フォーマットルールは含めない）
Husky + lint-stagedをセットアップ — コミット前の自動チェックを設定

npmスクリプトを追加：

{
  "scripts": {
    "format": "prettier --write .",
    "format:check": "prettier --check .",
    "lint": "eslint .",
    "lint:fix": "eslint --fix ."
  }
}

コードベース全体に初回フォーマットを実行： npm run format
フォーマットされたコードを単一コミットとして記録 — git blameで--ignore-revを使って簡単にスキップできるようにする

実践でのフォーマット

フォーマットパイプラインを構築すれば、日々の開発体験は劇的に変わります：

好きなようにコードを書く。 Prettierが保存時やコミット時に再整形してくれる。
プルリクエストにはロジックの変更だけが表示される。 空白のノイズはもうありません。
新しいチームメンバーがすぐに戦力になる。 スタイルガイドのドキュメントなしでも、ツールが標準を強制してくれる。
スタイルに関する議論がなくなる。 権威あるのは個々の開発者ではなく、Prettierである。

作業中のJSONデータの構造を確認したいときは、JSON Formatterが便利です——任意のJSONを貼り付けるだけで、ブラウザ上で即座に読みやすいフォーマットが得られます。

JavaScriptコードフォーマット：ツールと標準規約

本記事では、JavaScriptのフォーマットを「解決済みの問題」にするためのツールと標準規約を紹介します。

なぜ統一されたフォーマットが重要なのか

解決策は「どのスタイルが一番良いか」を議論することではありません。一つを選び、自動化することです。

主要なJavaScriptスタイルガイド

ツールを選ぶ前に、JavaScriptのフォーマット慣習を形作ってきた主要なスタイルガイドを理解しておくと役立ちます。

Airbnb Style Guide

// Airbnb style
const getUserData = (userId) => {
  const user = findUser(userId);
  return {
    name: user.name,
    email: user.email,
  };
};

Standard Style

// Standard style
const getUserData = (userId) => {
  const user = findUser(userId)
  return {
    name: user.name,
    email: user.email
  }
}

Google Style Guide

Prettier：独自の主張を持つフォーマッター

インストール

npm install --save-dev prettier

.prettierrc設定ファイルを作成します：

{
  "printWidth": 80,
  "tabWidth": 2,
  "useTabs": false,
  "semi": true,
  "singleQuote": true,
  "trailingComma": "all",
  "bracketSpacing": true,
  "arrowParens": "always"
}

主要な設定オプション

semi（デフォルト：true） — 文の末尾にセミコロンを付けるかどうかです。Standard Styleを好む場合はfalseに設定します。

// 末尾カンマなし — "d"を追加すると2行が変更される
const items = [
-  "a",
-  "b",
-  "c"
+  "a",
+  "b",
+  "c",
+  "d"
];

// 末尾カンマあり — "d"を追加すると1行だけ変更される
const items = [
  "a",
  "b",
  "c",
+  "d",
];

arrowParens（デフォルト："always"） — アロー関数の単一パラメータを括弧で囲むかどうかです。"always"は(x) => x、"avoid"はx => xになります。

Prettierの実行

# すべてのファイルをフォーマット
npx prettier --write .

# 変更せずにチェックのみ
npx prettier --check .

# 特定のファイルタイプをフォーマット
npx prettier --write "src/**/*.{js,jsx,ts,tsx}"

生成されたファイルをスキップするために.prettierignoreファイルを追加します：

node_modules
dist
build
coverage
*.min.js

圧縮されたJavaScriptを扱う場合は、Code Minifierが適切に圧縮を処理します——圧縮されたコードを手動で編集するのはやめましょう。

ESLint：フォーマットを超えて

フォーマットルール — インデント、スペース、括弧の配置など。これらはPrettierと重複するため、両方を使う場合は一般的に無効にすべきです。

コード品質ルール — 未使用変数、到達不能コード、暗黙の型変換、エラー処理の欠如など。ESLintが真価を発揮するのはこちらです。

推奨セットアップ

npm install --save-dev eslint @eslint/js

最小限のeslint.config.js：

import js from '@eslint/js';

export default [
  js.configs.recommended,
  {
    rules: {
      'no-unused-vars': 'warn',
      'no-console': 'warn',
      'eqeqeq': 'error',
      'no-implicit-coercion': 'error',
    },
  },
];

TypeScriptプロジェクトの場合はtypescript-eslintを追加します：

npm install --save-dev typescript-eslint

import js from '@eslint/js';
import tseslint from 'typescript-eslint';

export default tseslint.config(
  js.configs.recommended,
  ...tseslint.configs.recommended,
);

Prettier + ESLintの連携

npm install --save-dev eslint-config-prettier

import js from '@eslint/js';
import prettierConfig from 'eslint-config-prettier';

export default [
  js.configs.recommended,
  prettierConfig,
  {
    rules: {
      // コード品質ルールのみここに記述
      'no-unused-vars': 'warn',
      'eqeqeq': 'error',
    },
  },
];

このセットアップにより、フォーマットはPrettierが、コード品質はESLintがそれぞれ担当します。競合もなく、混乱もありません。

EditorConfigによるエディタ間の一貫性

プロジェクトルートに.editorconfigファイルを作成します：

root = true

[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[*.md]
trim_trailing_whitespace = false

HuskyとWSlint-stagedによるGitフック

セットアップ

npm install --save-dev husky lint-staged
npx husky init

package.jsonに追加します：

{
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "prettier --write",
      "eslint --fix"
    ],
    "*.{json,md,css}": [
      "prettier --write"
    ]
  }
}

Huskyのpre-commitフック（.husky/pre-commit）を更新します：

npx lint-staged

セミコロン論争

一つを選び、Prettierのsemiオプションを設定して、次に進みましょう。Prettierがどちらの場合でも一貫して追加または削除してくれます。

JavaScriptにおけるタブ vs スペース

Prettier（tabWidth: 2, useTabs: false）とEditorConfig（indent_style = space, indent_size = 2）で一度設定すれば、それで決着です。

よくあるフォーマットの落とし穴

アロー関数の不統一

// 不統一 — これは避けましょう
const double = x => x * 2;
const add = (a, b) => a + b;
const greet = (name) => {
  return `Hello, ${name}`;
};

// 統一 — PrettierでarrowParens: "always"を使用
const double = (x) => x * 2;
const add = (a, b) => a + b;
const greet = (name) => {
  return `Hello, ${name}`;
};

オブジェクト分割代入のスタイル

// 詰まっている — 読みにくい
const {name,email,role} = user;

// 整形済み — Prettierが自動的に処理
const { name, email, role } = user;

// プロパティが多い場合は複数行に
const {
  name,
  email,
  role,
  department,
  startDate,
} = user;

import文の整理

// 整理されたimport
import React from 'react';
import { useState, useEffect } from 'react';

import { Button } from '@/components/Button';
import { Modal } from '@/components/Modal';

import { formatDate } from '../utils/dates';
import { validateEmail } from '../utils/validation';

長い三項演算子

// 1行では読みにくい
const label = isAdmin ? 'Admin Dashboard' : hasEditPermission ? 'Editor View' : 'Read Only';

// Prettierが読みやすい複数行に再整形
const label = isAdmin
  ? 'Admin Dashboard'
  : hasEditPermission
    ? 'Editor View'
    : 'Read Only';

新規プロジェクトのセットアップ

新しいJavaScriptまたはTypeScriptプロジェクトの完全なセットアップチェックリストです：

依存パッケージのインストール：

npm install --save-dev prettier eslint eslint-config-prettier husky lint-staged

.prettierrcを作成 — チームの好みに合わせた設定を記述
.editorconfigを作成 — エディタ間のベースラインを設定
ESLintを設定 — コード品質ルールのみ（フォーマットルールは含めない）
Husky + lint-stagedをセットアップ — コミット前の自動チェックを設定

npmスクリプトを追加：

{
  "scripts": {
    "format": "prettier --write .",
    "format:check": "prettier --check .",
    "lint": "eslint .",
    "lint:fix": "eslint --fix ."
  }
}

コードベース全体に初回フォーマットを実行： npm run format
フォーマットされたコードを単一コミットとして記録 — git blameで--ignore-revを使って簡単にスキップできるようにする

実践でのフォーマット

フォーマットパイプラインを構築すれば、日々の開発体験は劇的に変わります：

好きなようにコードを書く。 Prettierが保存時やコミット時に再整形してくれる。
プルリクエストにはロジックの変更だけが表示される。 空白のノイズはもうありません。
新しいチームメンバーがすぐに戦力になる。 スタイルガイドのドキュメントなしでも、ツールが標準を強制してくれる。
スタイルに関する議論がなくなる。 権威あるのは個々の開発者ではなく、Prettierである。

JavaScriptコードフォーマット：ツールと標準規約

なぜ統一されたフォーマットが重要なのか

主要なJavaScriptスタイルガイド

Airbnb Style Guide

Standard Style

Google Style Guide

Prettier：独自の主張を持つフォーマッター

インストール

主要な設定オプション

Prettierの実行

ESLint：フォーマットを超えて

推奨セットアップ

Prettier + ESLintの連携

EditorConfigによるエディタ間の一貫性

HuskyとWSlint-stagedによるGitフック

セットアップ

セミコロン論争

JavaScriptにおけるタブ vs スペース

よくあるフォーマットの落とし穴

アロー関数の不統一

オブジェクト分割代入のスタイル

import文の整理

長い三項演算子

新規プロジェクトのセットアップ

実践でのフォーマット

関連リソース

JavaScriptコードフォーマット：ツールと標準規約

なぜ統一されたフォーマットが重要なのか

主要なJavaScriptスタイルガイド

Airbnb Style Guide

Standard Style

Google Style Guide

Prettier：独自の主張を持つフォーマッター

インストール

主要な設定オプション

Prettierの実行

ESLint：フォーマットを超えて

推奨セットアップ

Prettier + ESLintの連携

EditorConfigによるエディタ間の一貫性

HuskyとWSlint-stagedによるGitフック

セットアップ

セミコロン論争

JavaScriptにおけるタブ vs スペース

よくあるフォーマットの落とし穴

アロー関数の不統一

オブジェクト分割代入のスタイル

import文の整理

長い三項演算子

新規プロジェクトのセットアップ

実践でのフォーマット

関連リソース