Formatting SQL for Readable Code Review (Without Pretending It Validates It)

Why formatting SQL helps review

Most SQL bugs are structural - a join without a condition, an OR that should have been parenthesised, a SELECT * that now drags a huge column. Those hide in one-line queries and stand out when each clause is on its own line with aligned keywords. A formatted query lets a reviewer read intent, not parse soup, and keeps diffs readable because the layout is stable.

The tool formats in the browser with a formatting library and offers spaces or tabs, an indent size, plus copy and download - enough to turn a wall of text into something a colleague can approve at a glance.

What a formatter does not do

It is essential to be clear about the limits. A beautifier reflows characters; it cannot know whether your identifiers exist, whether a foreign key is valid, whether a GROUP BY matches the non-aggregated columns for your dialect, or whether the query will be fast. A perfectly formatted query can still be wrong, insecure, or a full-table-scan disaster.

Formatting is the cosmetic layer between text and the database. Real validation happens in the database (a dry-run, a transaction you roll back, a migration in staging), and real performance answers come from EXPLAIN, not from pretty indentation.

Use all three: format to review, validate against the database to confirm it is legal, and EXPLAIN to confirm it is sane - each catches what the others cannot.

Choosing a house style

Consistency is the actual win, so agree on one style and let the formatter enforce it mechanically: keywords uppercase, one column or one table per line, indentation width, and where joins and conditions wrap. The formatter lets you set spaces versus tabs and indent size, so pick the values your linter or CI expects and stop hand-formatting debates.

Because SQL dialects differ (MySQL, PostgreSQL, T-SQL, Oracle), remember that a generic formatter may not special-case dialect syntax; treat formatting as a first pass and let the target database have the final word.

A review workflow that actually catches bugs

Format first, then read for logic: scan for the missing WHERE on a DELETE/UPDATE, joins without conditions, SELECT * in stored views, unparameterised values that invite injection, and ORDER BY on non-indexed columns. Only after a human signs off do you run it against the database and check the plan. The same beautify idea helps across languages - the JSON formatter and HTML beautifier are its siblings.

For migrations and large pull requests, committed formatted SQL reduces diff noise, so reviewers see the change rather than re-indentation churn.