How to Format SQL Queries Before Code Review
A 200-character single-line SQL query is technically correct and practically unreviewable. Reviewers end up mentally re-indenting the query before they can even start checking the logic, which means real bugs — a missing JOIN condition, an unintended cross join, a WHERE clause that doesn't match the intent — get less attention than they deserve. Formatting SQL before opening a PR is a small habit with an outsized effect on review quality.
Key Takeaways
- Unformatted SQL forces every reviewer to re-indent it mentally before reviewing logic, wasting reviewer attention on structure instead of correctness
- Consistent keyword casing and indentation make JOIN conditions and WHERE clauses easy to scan at a glance
- Formatting doesn't change query behavior — it's purely for humans, so it's always safe to apply before a commit
- A missing JOIN condition is far easier to spot in formatted SQL, where each clause is on its own line
- Different SQL dialects (MySQL, PostgreSQL, T-SQL) have different quoting and syntax quirks a formatter should respect
1. Format before you write the PR description, not after
Format the query as the last step before committing, not as an afterthought once review comments start coming in. If you reformat mid-review, the diff view makes it look like the whole query changed, burying the actual logic changes a reviewer already commented on.
2. Pick a consistent keyword case and stick to it
Whether your team prefers UPPERCASE keywords (SELECT, FROM, WHERE) or lowercase, consistency matters more than which one you pick. Mixed casing across a codebase — some queries UPPER, some lower, some mixed — adds visual noise that makes it harder to instantly distinguish keywords from column and table names.
3. Put each JOIN and its condition on its own line
The highest-value formatting choice for review is giving every JOIN its own line, directly followed by its ON condition. This is where the most expensive SQL bugs hide: a JOIN with a wrong or missing condition silently turns into a cross join, multiplying row counts and producing subtly wrong aggregates that are hard to spot in a wall of text but jump out immediately when each join is isolated on its own line.
4. Align WHERE, GROUP BY, and ORDER BY clauses vertically
Multiple conditions in a WHERE clause, or multiple columns in GROUP BY/ORDER BY, should each get their own line with consistent indentation. This makes it trivial to spot a missing AND, an OR that should have been an AND (a classic precedence bug), or a GROUP BY that doesn't match every non-aggregated column in the SELECT.
5. Confirm the dialect before formatting
MySQL, PostgreSQL, SQL Server (T-SQL), and SQLite differ in quoting rules (backticks vs double quotes vs brackets), date functions, and some clause syntax (LIMIT vs TOP vs FETCH). Format with the correct dialect selected — auto-formatting a T-SQL query with generic SQL rules can silently change semantics like identifier quoting.
Common Mistakes to Avoid
- ✗Reformatting a query mid-review, which makes the diff unreadable and buries prior review comments
- ✗Mixing keyword casing across the same codebase or even the same query
- ✗Writing multi-table JOINs as one long line instead of one JOIN + ON pair per line
- ✗Formatting with the wrong SQL dialect selected, which can change quoting semantics
- ✗Assuming formatting also validates the query — formatting only affects whitespace and casing, not correctness
Frequently Asked Questions
Does formatting a SQL query change how it executes?▾
No. Formatting only changes whitespace, indentation, and keyword casing — it has no effect on query execution, as long as the formatter correctly respects your database's quoting and syntax rules for identifiers and string literals.
What is the single most important thing to check in a formatted query during review?▾
JOIN conditions. A missing or incorrect ON clause silently turns an INNER JOIN into an unintended cross join, which multiplies rows and corrupts aggregates without throwing any error — and it's far easier to catch when each JOIN and its condition sits on its own line.
Should I format SQL embedded inside application code (e.g., a Python or PHP string)?▾
Yes, for any query complex enough to need review — format the SQL text itself (ignoring the surrounding language syntax), then paste it back into the string literal. A one-line query embedded in code is exactly as hard to review as one committed to a .sql file.
Related Tools
Related Guides
How to Debug API JSON Responses Safely in the Browser
A practical workflow for inspecting, formatting, and comparing API JSON responses in the browser without pasting sensitive data into random online tools.
How to Minify Code Before Production
A practical checklist for minifying CSS, JavaScript, HTML, and JSON before deployment — what to minify, what to keep readable, and how to avoid shipping a silently broken build.
Last reviewed: 2026 · Written and verified by the Dev Utilities team · Editorial policy
Report an issue with this guide →