SQLフォーマッター

整形前と整形後

整形前:

SELECT u.id,u.name,COUNT(o.id) AS orders FROM users u LEFT JOIN orders o ON o.user_id=u.id WHERE u.created_at>='2024-01-01' GROUP BY u.id,u.name HAVING COUNT(o.id)>5 ORDER BY orders DESC LIMIT 50;

整形後（先頭カンマ、大文字キーワード、2スペースインデント）:

SELECT
    u.id
  , u.name
  , COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o
  ON o.user_id = u.id
WHERE u.created_at >= '2024-01-01'
GROUP BY u.id, u.name
HAVING COUNT(o.id) > 5
ORDER BY orders DESC
LIMIT 50;

重要なスタイルの選択

• キーワードの大文字と小文字。 UPPERCASEは伝統的で見つけやすいです。小文字は、構文ハイライトのある最新のコードエディタではすっきり見えます。
• 先頭カンマと末尾カンマ。 先頭（ , col）は1つの列をコメントアウトしやすいです。末尾（col,）はテキストとして自然に読めます。
• GROUP BYのカンマ位置。 長い句では1行に1つ、短い句ではインラインにすることが多いです。
• JOINのインデント。 次の行にONを置く（ぶら下げインデント）か、同じ行に置くか。長い条件はぶら下げが向きます。
• サブクエリ。 開きカッコだけでなく、サブクエリ全体をインデントします。

方言ごとの落とし穴

• 識別子におけるMySQLのバッククォートとPostgreSQLのダブルクォート。
• WITH CTE、MS SQLはWITHの前に;が必要です。フォーマッターがこれを処理します。
• ウィンドウ関数、長いOVER (...)句は、PARTITION BYとORDER BYを改行で折り返すと読みやすくなります。
• BigQueryにはARRAY_AGG、STRUCT、テーブルのサフィックス（*_yyyymmdd）があり、トークナイザーはこれらを壊してはいけません。
• Oracleには(+)の外部結合構文があります。フォーマッターはこれを保持しつつ、レガシーとして印を付けます。

フォーマッターが行わないこと

• バグの修正、不正なJOINは不正なままです。
• SELECT *の展開、列リストはスキーマから推測しません。
• クエリの最適化、レイアウトのみで、実行計画は扱いません。
• サブクエリのCTEへの書き換え、別の関心事です。