SQL Formatter

Before and after

Before:

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;

After (leading comma, uppercase keywords, 2-space indent):

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;

Style choices that matter

• Uppercase vs lowercase keywords. UPPERCASE is traditional and scannable. Lowercase is cleaner in modern code editors with syntax highlighting.
• Leading vs trailing commas. Leading ( , col) makes it easier to comment out a single column. Trailing (col,) reads more naturally in text.
• Comma placement in GROUP BY. Often one per line for long clauses, inline for short ones.
• JOIN indentation. ON on the next line (hanging indent) vs on the same line. Long conditions benefit from hanging.
• Subqueries. Indent the whole subquery, not just the opening paren.

Dialect-specific gotchas

• MySQL backticks vs PostgreSQL double-quotes for identifiers.
• WITH CTEs, MS SQL has a ; requirement before WITH; the formatter handles it.
• Window functions, long OVER (...) clauses benefit from line-wrapped PARTITION BY and ORDER BY.
• BigQuery has ARRAY_AGG, STRUCT and table suffixes (*_yyyymmdd) that the tokenizer must not break.
• Oracle has (+) outer-join syntax, the formatter preserves it but flags it as legacy.

What the formatter does not do

• Fix bugs, an invalid JOIN stays invalid.
• Expand SELECT *, column lists are not inferred from schema.
• Optimize queries, layout only, not execution plans.
• Rewrite subqueries as CTEs, a different concern.