Learn SQL formatting conventions that make your queries easier to read, maintain, and debug. Covers indentation, keyword casing, JOIN formatting, subqueries, and establishing team standards.
SQL formatting is one of those things I never thought about until I had to review someone else's 200-line query. Unformatted SQL is basically unreadable - I've stared at nested subqueries for 20 minutes before realizing there was a missing JOIN.
Now I'm religious about formatting. At Šikulovi s.r.o., I've gotten our team to adopt consistent standards, and it's made code reviews actually possible. Here's everything I've learned about making SQL readable.
I used to think formatting was cosmetic. Then I spent 3 hours debugging a query only to find I'd duplicated a JOIN condition. With proper formatting, I'd have seen it in seconds.
UPPERCASE or lowercase? Here's the thing: it genuinely does not matter which you pick. What matters is picking one and sticking to it.
This is where formatting actually matters. Every major clause on its own line. Period.
Most people put commas at the end of lines. I put them at the start. Here is why:
I've seen production queries with 15 JOINs. Formatting is the only thing that makes these survivable.
Common Table Expressions changed how I write SQL. When a query gets complex, I reach for WITH clauses instead of nested subqueries.
Because it might. I once saw a DELETE without WHERE that wiped a production table. The WHERE was there - just hidden at the end of a long line nobody read.
Manual formatting is a waste of time. I format on save and never think about it.
After years of tweaking, here is my actual style:
Your SQL formatting does not have to match mine. What matters is that your team picks a style and enforces it automatically. The debates about uppercase vs lowercase, leading vs trailing commas - just make a decision and move on.
Get a formatter, configure it once, add it to pre-commit hooks, and never think about it again. Future you will be grateful.
Honestly, it does not matter. Pick one and stick with it. I use UPPERCASE out of habit, but lowercase is fine too. Just be consistent across your codebase.
I prefer leading commas because commenting out a column is cleaner. But trailing commas work fine too. The important thing is that everyone on your team does the same thing.
Each JOIN on its own line, ON condition indented below, AND conditions on separate lines starting with AND. Always use explicit JOIN syntax - never comma-separated tables in the FROM clause.
Whenever nesting gets more than 2 levels deep, or when you need to reference the same subquery multiple times. CTEs make complex queries readable by giving each piece a name.
sqlfluff for CI/CD, your editor's built-in formatter for daily work, and the SQL Formatter on this site when you're working in a browser. Whatever you pick, add it to pre-commit hooks.
Automate it. Pick a formatter, configure it, add it to pre-commit hooks. Nobody should have to think about formatting - it should just happen.
Founder of CodeUtil. Web developer building tools I actually use. When I'm not coding, I experiment with productivity techniques (with mixed success).
Learn the critical differences between escaping and parameterized queries for SQL injection prevention. Understand why parameterization is the gold standard for database security.
Ever tried to debug minified production code? I have. It's like reading a novel with no spaces or punctuation. Here's how code beautification saves hours of debugging time.
camelCase, snake_case, kebab-case - why do we have so many? Here's what I've learned about naming conventions, when to use each style, and why consistency matters more than the 'right' choice.