HTML / CSS / JS / SQL / XML フォーマッター完全比較

なぜフォーマッターを使うのか

フォーマッターを導入するかどうか迷う人に、真顔で答えたいのは「迷うくらいなら入れたほうが 100 倍ラク」という一点です。理由は単純で、フォーマッターは 本質でない議論を消してくれる道具 だから。コードレビューで「ここインデントズレてる」「ここ空行多い」と指摘する時間は、本来アーキテクチャや命名やアルゴリズムを議論する時間に使うべきだった時間です。フォーマッターを入れれば、こうした指摘は「ツールが自動で直すもの」になり、人間の視界から消えます。

具体的にもたらされる効果は大きく分けて 4 つあります。第一に 可読性の統一。誰が書いても同じ見た目になるので、ファイルを開いた瞬間に「あ、別の人が書いた」と脳のモードを切り替える必要がありません。第二に レビュー効率。diff が純粋にロジックの差分だけになるので、レビュアーは本質に集中できます。第三に 無意味な diff の削減。タブとスペースの混在、行末の空白、末尾改行の有無——こうしたものは git の blame や履歴を汚しますが、フォーマッターがあれば初めから発生しません。第四に 新メンバーの立ち上がり。プロジェクトのスタイル規約を口頭や Wiki で伝える必要がなく、「npm run format を実行すれば正しくなる」で済みます。オンボーディング 1 日目にスタイル問題で詰まる人が激減します。

逆に「フォーマッターを入れないほうがいい場面」はほとんどありません。唯一の例外は、フォーマッターが対応していない言語・ファイル形式を触っているときと、既存コードの初回フォーマットでコミット履歴をどう扱うか悩んでいるときくらいです。後者も「一度大きな整形コミットを作ってから blame 除外ファイルに記録する」という定番パターンで解決できます（.git-blame-ignore-revs が便利）。

フォーマッターは「性能改善」や「新機能」のように派手な成果は生みません。でも、長く続くプロジェクトほどボディブローのように効いてきます。1 年後に「そういえば最近インデント論争しなくなったね」と気づくタイプの投資です。

インデント流儀（タブ vs スペース）

インデントの流儀は言語文化によって大きく違います。「どっちが正しいか」ではなく「どっちが根付いているか」で決めるのが現実的です。主要言語の慣習をまとめました。

• Python: PEP 8 で 4 スペース推奨。歴史的にタブとスペースの混在で InconsistentIndentation エラーに泣かされた経緯があり、Python 3 では混在そのものが禁止された。
• Go: gofmt がタブを強制。言語に同梱されたフォーマッターが存在する珍しい例で、議論の余地がゼロ。
• JavaScript / TypeScript: Prettier は 2 スペースがデフォルト。Airbnb や Google のスタイルガイドも 2 スペース。
• Ruby: 2 スペース。Rails コミュニティでは rubocop が既定。
• C / C++: プロジェクトごとに揺れる。Linux カーネルはタブ（8 カラム幅）、Google C++ Style Guide は 2 スペース。
• Java: Google Java Style は 2 スペース、Oracle 標準は 4 スペース。
• HTML / CSS: 2 スペースが多数派。Prettier デフォルトも 2。

「タブか、スペースか」の論争はかれこれ 30 年続いてきましたが、近年は アクセシビリティ観点 から「タブのほうが中立的に優れている」という主張が盛り返しています。タブはエディタ側で表示幅を変えられるため、視覚障害で大きな表示幅を必要とする人は 8 カラムに、狭い画面の人は 2 カラムに、といった ユーザー側の選択肢 が残せます。スペースでインデントしてしまうと「書いた人の好み」がファイルに焼き付けられ、読み手が変更できません。Linux カーネルや Go がタブを選んでいる背景にも、こうした理由があります。

とはいえ、Prettier が 2 スペースをデフォルトにしたことで JS/TS ではスペース派が圧倒的になり、個人の好みで揉める余地はほぼなくなりました。チームの言語文化に従う——これが最もコスパのいい選択です。.editorconfig を 1 ファイル置いておくと、エディタが自動でインデント幅やタブ / スペースを合わせてくれるので、導入しておいて損はありません。

# .editorconfig の例
root = true

[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true

[*.{js,ts,jsx,tsx,html,css,scss,json,yml,yaml}]
indent_style = space
indent_size = 2

[*.{py}]
indent_style = space
indent_size = 4

[*.go]
indent_style = tab

[Makefile]
indent_style = tab

ポイントは [Makefile] セクション。Makefile はタブでインデントしないと構文エラーになる言語なので、スペース派プロジェクトでも Makefile だけはタブに明示的に切り替える必要があります。エディタがうっかりスペースに変換してコミットすると、Make が missing separator を吐いて後輩が半日潰します（定番の落とし穴）。

HTML フォーマッターの特徴

HTML の整形が他の言語と違うのは、「空白に意味がある」 という点です。インラインで <span>こんにちは</span>世界 と書かれているとき、タグの前後に改行を入れると表示上の空白が変わってしまいます。フォーマッターはこれを 壊さないように 動く必要があり、思ったより繊細な処理をしています。

Prettier の HTML フォーマッタは次のルールで動きます。まず、タグを「ブロック要素」「インライン要素」「プリフォーマット要素」の 3 種類に分類します。<div>, <section>, <article> などはブロックで、改行を自由に入れてよいグループ。<span>, <a>, <strong> などはインラインで、前後の空白を保存するグループ。そして <pre> と <textarea> は プリフォーマット として扱われ、中身はフォーマッターが一切触りません。これを知らないと「<pre> の中が崩れた！」と騒ぐことになります（実際は崩れておらず、むしろ守られている）。

属性が多いタグの改行判断も重要なポイントです。Prettier は 1 行の長さが printWidth（デフォルト 80 文字）を超えると、属性を 1 行 1 つずつ縦に並べ直します。閾値を超えなければ 1 行のままです。

<div class="card"  id="main"
   data-role="hero"    data-theme="dark">
<h1>Hello</h1><p>World</p>
</div>

<div
  class="card"
  id="main"
  data-role="hero"
  data-theme="dark"
>
  <h1>Hello</h1>
  <p>World</p>
</div>

ツールとしての選択肢は大きく 2 つ。Prettier は AST ベースで厳密に整形し、設定が少なく一貫性が高い。一方 js-beautify は 10 年以上の歴史があり、細かい設定（属性の改行しきい値、void 要素の自己閉じ、空行の数など）を自由に調整できます。Prettier はチーム向け、js-beautify は「自分の流儀で細かく揃えたい」人向け、と覚えておくと選びやすいでしょう。

CSS の整形

CSS のフォーマッターは比較的シンプルです。基本ルールは「1 プロパティ 1 行」「セレクタの後ろに半角スペース → {」「セレクタブロックの間に空行」の 3 つ。これだけ揃えておけば、どの整形ツールを使ってもだいたい同じ見た目になります。

.card{background:#fff;padding:16px;border:1px solid #ddd;}
.card h2{font-size:20px;margin:0 0 8px;}

.card {
  background: #fff;
  padding: 16px;
  border: 1px solid #ddd;
}

.card h2 {
  font-size: 20px;
  margin: 0 0 8px;
}

気をつけたいのは shorthand（短縮記法）の扱い です。Prettier は基本的に元のコードのままで、margin: 0 0 8px を margin-top: 0; margin-right: 0; margin-bottom: 8px; に展開したり、逆に結合したりはしません。一方で Stylelint に shorthand-property-no-redundant-values ルールを入れておくと、margin: 10px 10px 10px 10px を margin: 10px に自動で縮約してくれます。Prettier がフォーマット、Stylelint がロジック修正、と役割を分けるのが現代の定石です。

もうひとつよく議論になるのが プロパティの並び順。大きく 3 つの流儀があります。

• アルファベット順: background → border → color → display……。機械的で揉めないが、意味のまとまりは失われる。Stylelint の order/properties-alphabetical-order で強制可能。
• SMACSS / Concentric: 外側（position, display, box）から内側（font, color）へ並べる。意味的に読みやすいが、覚えるのが大変。
• グループ化: レイアウト系 → ボックス系 → タイポグラフィ → 装飾 の順で並べる。多くのチームが独自定義している。

どれを選んでも「自動で並び替えてくれる」のが重要で、手動で揃えようとすると絶対に破綻します。Stylelint の stylelint-order プラグインを入れておけば、保存時 / コミット時に並べ替えが走って全員同じ順序になります。

カスタムプロパティ（CSS 変数）は大文字小文字を区別する点にも注意。--Main-Color と --main-color は別物として扱われます。フォーマッターは大文字小文字を変えないので、命名規則はチームで決めて Stylelint で弾くのが安全です。

JS / TS フォーマッター（Prettier 流）

JS/TS のフォーマッターはほぼ Prettier 一強 です。2017 年以降、ESLint の eslint:recommended からスタイル系ルールは eslint/stylistic 系に切り出され、さらに「フォーマッター任せにしてルールで検知しない」という流儀が一般化しました。2023 年には ESLint 自身もスタイル系ルールを deprecated 扱い にしています。今から新規プロジェクトを始めるなら「Prettier でフォーマット、ESLint でロジック検査」と役割を分けるのが最適解です。

Prettier の主要な設定項目は驚くほど少なく、意図的にそうしています。よく触るのは次の 5 つくらいです。

// .prettierrc
{
  "printWidth": 80,
  "tabWidth": 2,
  "useTabs": false,
  "semi": true,
  "singleQuote": false,
  "trailingComma": "all",
  "arrowParens": "always",
  "endOfLine": "lf"
}

• printWidth: 1 行の目安長。80 がデフォルトで、100 にするチームも多い。長くしすぎると縦スクロールと横スクロールの両方が必要になるので 100〜120 が実用上の上限。
• semi: セミコロン有り / 無し。standard.js は無しだが、ASI（自動セミコロン挿入）の罠を避けたいなら有りが安全。
• singleQuote: シングルクォートを使うか。JSX は別に jsxSingleQuote がある。
• trailingComma: 末尾カンマ。"all" にしておくと diff が最小化されるので推奨。
• arrowParens: アロー関数の引数カッコ。"always" にしておくと後から型注釈を追加しやすい。

ESLint との関係整理も重要です。ざっくり言うと、Prettier は「見た目」、ESLint は「意味」。未使用変数、== vs ===、let が const であるべきか、といった コードの意味に踏み込むチェック は ESLint の仕事。インデントやクォート、カンマの位置は Prettier の仕事。両者が衝突しないよう eslint-config-prettier を入れて、ESLint のスタイル系ルールを無効化しておくのが定番セットです。

const user={name:'Alice',age:30,tags:['admin','dev',]}
function greet( name ){return `Hello, ${name}!`}

const user = {
  name: "Alice",
  age: 30,
  tags: ["admin", "dev"],
};

function greet(name) {
  return `Hello, ${name}!`;
}

SQL の整形

SQL のフォーマッターは「好みが出る」「方言差が大きい」「決定版がない」という 3 重苦で、JS/TS ほど簡単ではありません。主な選択肢は次の 3 つです。

• sql-formatter: Node.js 製。20 以上の方言（Postgres, MySQL, BigQuery, Snowflake, Oracle, Redshift…）に対応。ブラウザでも動く。ベンリーの SQL フォーマッター が内部で採用。
• pg_format: Perl 製。Postgres 向けに特化し、方言への追従度が高い。apt install pgformatter で入る。
• sqlfluff: Python 製。フォーマッター兼 Linter で、Jinja テンプレートを含む dbt プロジェクトでも動く。CI 向き。

SQL 整形で流儀が分かれるポイントは大きく 4 つあります。

• キーワードの大文字 / 小文字: SELECT か select か。歴史的には大文字派が主流で、黒い背景の端末で視認性が高いという理由から始まった。現代はエディタでシンタックスハイライトが効くので小文字派も増えている。
• カンマの位置: 後置 a, b, c と前置 , a , b , c。前置はコメントアウトしやすい・末尾カンマでエラーになりにくい、という実用メリットがある。
• JOIN のインデント: FROM と同じレベルに揃えるか、さらにインデントするか。
• サブクエリのネスト深さ: CTE（WITH 句）に書き換えるかどうか。これは整形ではなくリファクタリングの領域。

select u.id,u.name,count(o.id) as order_count from users u left join orders o on o.user_id=u.id where u.active=true group by u.id,u.name order by order_count desc limit 10;

SELECT
  u.id,
  u.name,
  COUNT(o.id) AS order_count
FROM users u
  LEFT JOIN orders o ON o.user_id = u.id
WHERE u.active = true
GROUP BY u.id, u.name
ORDER BY order_count DESC
LIMIT 10;

方言差の扱いは要注意です。たとえば BigQuery の STRUCT 型リテラルや Snowflake の QUALIFY 句、Postgres の RETURNING 句、MySQL の ON DUPLICATE KEY UPDATE は、方言を正しく指定しないと整形器がパースに失敗して素の文字列を返してきます。sql-formatter を使うときは language オプションで明示するのが鉄則です。

// sql-formatter を Node.js で使う例
import { format } from "sql-formatter";

const formatted = format(sqlText, {
  language: "bigquery",
  keywordCase: "upper",
  indentStyle: "standard",
  logicalOperatorNewline: "before",
});

最後に、SQL の整形が他と違う点をひとつ。SQL は「実行前に人間が目で追う」ケースが多く、整形の目的が「機械のため」ではなく「人間のための可読性」です。そのため、チーム内でスタイルがひとつ決まっていれば、多少クセがあっても統一されていることのほうが重要です。「うちは小文字派で前置カンマ」みたいな謎ルールでも、全員で守れていれば正解。

XML の整形

XML のフォーマットは「壊さないこと」が最大のテーマです。XML は空白の扱いが仕様レベルで定義されており、xml:space="preserve" 属性が付いている要素の中身はツールが触ってはいけません。これを無視して整形すると、SOAP のシグネチャや SVG のテキスト位置が破壊されます。

<book><title>SQL入門</title><authors><author id="1">田中</author><author id="2">鈴木</author></authors></book>

<book>
  <title>SQL入門</title>
  <authors>
    <author id="1">田中</author>
    <author id="2">鈴木</author>
  </authors>
</book>

XML 特有のチェックポイントは次のとおりです。

• CDATA セクション: <![CDATA[ ... ]]> の中身は生テキストとして扱う必要があり、整形してはいけない。内部に HTML やスクリプトが入っていることが多く、壊すと SOAP 応答が無効になる。
• 処理命令（PI）: <?xml version="1.0"?> や <?xml-stylesheet ... ?>。先頭にそのまま残し、前後に余計な空白を入れない。
• 属性の改行: 属性が多いときの改行方針は HTML と同じ考え方だが、XML は意味論的な空白が厳しいので、xml:space="preserve" を見たら即停止するのが安全。
• 名前空間プレフィックス: xmlns:soap のような宣言は長くなりがちで、Prettier などは自動改行する。デコーダは問題なく受理するが、手書きツールで差分が大きくなるので注意。
• 末尾改行: XML 宣言と整形後の末尾改行が抜けると、バリデータによっては警告を出すことがある。insert_final_newline = true を .editorconfig に入れておくのが安全策。

SVG は XML の一種なので、同じフォーマッターで整形できます。ただし Illustrator や Figma から書き出した SVG は <path> の d 属性が非常に長く、Prettier に渡すと「1 行 1 コマンド」に折り返されて見た目が大きく変わります。これは壊れているのではなく正しい挙動ですが、diff が膨らむのでリポジトリにコミットする前に一度だけ整形して以後は触らない、という運用が無難です。

各言語の公式スタイルガイド

フォーマッターは「規約を機械的に適用する道具」ですが、その元になっている スタイル規約 は人間が書いた文書として別途存在します。フォーマッターに頼らず手で書くときや、フォーマッターのデフォルトから外れたいときに参照するものです。主要言語の代表的な規約を一覧にしました。

このなかで PEP 8 と PSR-12 は言語公式に近いものとして広く受け入れられており、コミュニティ全体が従っています。JS/TS の Airbnb は社内向けに始まったものが広まったパターンで、「公式」ではないけれど実質標準。Google 系は検索すればすぐ出てくるので、迷ったらどれかひとつ選んで採用すれば十分です。

重要なのは「スタイル規約を全部暗記する」ことではなく、「フォーマッターが規約をコードに反映してくれる状態を作る」こと。.prettierrc や .stylelintrc に設定を書いて、あとはコミット前に自動適用する。これでチーム全員が「実質 PEP 8 準拠」や「Airbnb 準拠」のコードを書けるようになります。

CI でフォーマット強制

フォーマッターを導入しただけでは、忘れて push する人が必ず出てきます。これを防ぐには CI でチェックを強制する 仕組みが必要です。3 段構えで守るのが定番パターンです。

1. エディタ: 保存時に自動フォーマット。ほとんどの人がここで止まる。
2. pre-commit フック: コミット前にフォーマット済みかチェック。エディタ設定を忘れた人をカバー。
3. CI: PR 作成時にフォーマット済みかチェック。フック回避したローカルコミットもここで止める。

pre-commit フックは husky や lefthook が代表的です。シンプルに使うなら lefthook のほうが早くて設定もわかりやすい、と個人的には思っています。

# lefthook.yml
pre-commit:
  parallel: true
  commands:
    prettier:
      glob: "*.{js,ts,jsx,tsx,html,css,json,md}"
      run: npx prettier --write {staged_files} && git add {staged_files}
    eslint:
      glob: "*.{js,ts,jsx,tsx}"
      run: npx eslint --fix {staged_files} && git add {staged_files}

CI（GitHub Actions）では「変更されていないか」を検査する --check モードを使います。書き換えはせず、整形済みでないファイルがあればジョブを失敗させる動きです。

# .github/workflows/lint.yml
name: Lint
on:
  pull_request:
  push:
    branches: [main]

jobs:
  format:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "20"
          cache: "npm"
      - run: npm ci
      - name: Check Prettier
        run: npx prettier --check .
      - name: Check ESLint
        run: npx eslint .
      - name: Check Stylelint
        run: npx stylelint "**/*.{css,scss}"

ローカルでチェックしたいときのコマンドも覚えておくと便利です。

# 変更せず整形済みかだけ確認
npx prettier --check .

# 実際に整形する
npx prettier --write .

# 特定のファイルだけ
npx prettier --write "src/**/*.{ts,tsx}"

ベンリーの 5 種フォーマッター使い分け

benry.me では、HTML・CSS・JS・SQL・XML の 5 種類のフォーマッターをブラウザ内で動かせるツールとして公開しています。すべて 入力はローカル完結（サーバー送信なし）なので、機密を含むコードを貼っても外部に出ることはありません。それぞれの特徴と使い分けをまとめました。

使い方はどれも同じで、左に貼って右をコピーして戻す だけ。VS Code などのエディタで Prettier を設定するのが面倒な場面、他人からもらったスニペットをサクッと整形したい場面、ブラウザの DevTools 経由で取得した minified コードを読みやすくしたい場面、などで便利です。

特に SQL フォーマッターは BigQuery / Postgres / MySQL / Snowflake / Redshift の方言切り替えに対応しているので、「SQL をコピペして方言を選ぶだけで整形」という用途にちょうど向いています。sqlfluff や pg_format をインストールするほどでもないけど、手元で 1 回だけ整形したい——そんなときに使ってみてください。

各言語の落とし穴

最後に、各言語のフォーマッターを使っていて「これは知らないと踏む」という落とし穴を 1 項目ずつまとめておきます。どれも実際に踏んだ人が愚痴をこぼしてきたやつです。

• HTML - <textarea> の中身が消えた問題: <textarea>初期値</textarea> の「初期値」を含む前後の改行や空白は、ブラウザ上でそのまま表示されます。フォーマッターが勝手に改行を入れると、テキストエリアに謎の空行が入って見えてしまいます。Prettier は対応済みですが、古いツールは要注意。
• SQL - 末尾セミコロン: PostgreSQL は文末セミコロンが必須、MySQL は対話モードで必須、SQLite は省略可。フォーマッターは元の SQL に合わせて付けたり外したりするので、方言設定を間違えると CI で「SQL が実行できない」と言われます。
• JS - autofix 後の空行: ESLint の autofix と Prettier を両方走らせると、空行の数が競合して「保存するたびに diff が出る」現象が起きます。解決策は eslint-config-prettier を最後にロードして ESLint の空行ルールを無効化すること。
• CSS - カスタムプロパティの大文字: --main-color と --Main-Color は別物です。フォーマッターはどちらも触らず残すので、命名規則が揺れていても気づきません。Stylelint の custom-property-pattern で正規表現を強制するのが安全策。
• XML - 末尾改行: ある種の XML パーサ（特に .NET 系）は、末尾改行がないと「不完全な文書」と判断して警告を出します。Prettier はデフォルトで末尾改行を付けますが、手書き YAML / XML では忘れがち。.editorconfig の insert_final_newline = true を必ず入れておきましょう。
• 共通 - 改行コード CRLF / LF の混在: Windows で開発している人が混ざると、保存のたびに CRLF / LF が切り替わって git の diff が全行変更になる。これも .editorconfig の end_of_line = lf と、Git の core.autocrlf = input 設定で解決できます。