SQLフォーマッター

完全な単語を正規表現と照合してキーワードを大文字化するフォーマッターは、ある「order」の出現がSQLキーワード`ORDER`（`ORDER BY`のような）なのか、たまたまその単語を含む文字列リテラル値なのかを知る方法がありません — `WHERE description = 'the order from stock'`で行をフィルタするクエリは、引用符で囲まれた文字列の中に「order」という単語を持っており、キーワードとしては全く機能していません。ナイーブなフォーマッターは文脈にかかわらずマッチしたすべての単語を大文字化し、文字列リテラル値を`'the ORDER FROM stock'`に破損させ、クエリが実際に何をフィルタするかを黙って変えてしまいます。クエリを正しくトークン化すること — 何がキーワードとしてカウントされるかを決める前に引用符で囲まれた文字列の境界を認識すること — がこれを防ぎます。そしてこれはまさに、SQLキーワードにたまたま一致する単語を含む実際のデータでのみ現れるバグであり、単純なサンプルクエリでテストする際には見落としやすいのです。

このツールは、PostgreSQL、MySQL、SQL Server、SQLite、Oracle間で共有される共通の句構造 — SELECT、FROM、WHERE、JOIN、GROUP BY、ORDER BYとその仲間 — を、各句を独自の行にインデントし、サブクエリを正しくネストできる程度によく認識します。特定のデータベースの完全な文法の完全な理解を構築することはなく、PostgreSQLの配列構文やSQL Serverの`TOP`句の配置のようなベンダー固有の拡張も含みません。実務上の帰結として、特定の方言固有の構文はエラーを起こすことなくフォーマッターをそのまま通過しますが、共通の句と同じ丁寧なインデントも受け取りません — これは、データベースエンジンごとに別々のツールを必要とするのではなく、単一のフォーマッターで5つの方言をサポートするための妥当なトレードオフです。

SQLキーワードは言語自体の仕様によって大文字小文字を区別しません — `SELECT`、`Select`、`select`はどのSQLエンジンにとっても同一です。これがまさに、それらを大文字または小文字にすることを、挙動を変えるリスクが一切ない純粋に装飾的な操作にしています。このフォーマッターが追加する空白と改行についても同じことが言えます: インデントされた12行に分割されたクエリは、1行に詰め込まれた同じクエリと同一に実行されます。整形は、どのテーブルが読まれるか、どの条件が行をフィルタするか、どんな値が挿入されるかを決める実際のトークンには何も触れません — 後でそれを読む人間のために、その同じ論理クエリを視覚的にどう配置するかだけです。

ORMによって生成された、データベースGUIからエクスポートされた、あるいは急いだマイグレーション中に長い1行として書かれたクエリは、機能的には正しいことが多いですが、書かれたとおりでは人間がレビューするのが本当に難しいことがよくあります — 改行のない15個のジョインを持つクエリは、どの条件がどのジョインに属するか、あるいはWHERE句が正しいテーブルをフィルタしているかを見るのを難しくします。各句と各ジョインを独自の行に再整形し、クエリの実際の構造を反映するようインデントすることは、コードレビューで承認する前や、なぜ間違った行を返すのかをデバッグする前に、生成された長いクエリが実際に何をするかを本当に理解する最速の方法であることが多いです。