SQL is one of the most widely used programming languages in the world, and unlike many languages it has no official formatting standard. This means SQL written by different developers often looks radically different. A well-formatted SQL query communicates its logic clearly; a poorly formatted one looks like a wall of text even to an experienced developer.
SQL Formatting Conventions
Keyword casing: SQL keywords (SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY, HAVING, INSERT, UPDATE, DELETE, etc.) are conventionally written in uppercase. Table and column names are written in whatever case the database uses (typically lowercase with underscores in PostgreSQL, or PascalCase in SQL Server). Consistent casing makes queries scannable at a glance.
One clause per line: each major clause starts on its own line. The SELECT clause lists the columns, each on its own line for complex queries. The FROM clause names the primary table. Each JOIN is on its own line with the ON condition indented below it. The WHERE clause starts on its own line with each condition on a subsequent line joined by AND or OR.
Indentation: subclauses, conditions, and nested subqueries are indented relative to their parent clause. This shows logical hierarchy.
Aliases: table aliases should be short but meaningful. Using the first letter of each word (as c for customers, oi for order_items) keeps queries concise without sacrificing readability.
Why Formatting Matters for Performance Debugging
When a query is running slowly and you need to add an index hint, rewrite a subquery as a join, or add a LIMIT clause, finding the right place in a poorly formatted query wastes time. A well-formatted query lets you navigate the logic immediately.
Code review of SQL is also much more effective when the formatting is consistent. Reviewers can focus on correctness and logic rather than parsing the structure.
Using the DevHexLab SQL Formatter
Open the tool at /tools/developer/sql-formatter. Paste your SQL. Select the dialect (MySQL, PostgreSQL, T-SQL, etc.) for dialect-specific keyword handling. The formatted query appears with consistent indentation and uppercase keywords. Copy and use it in your documentation, query editor, or source code.
Frequently Asked Questions
Should I format SQL in application code?
When SQL is built dynamically in application code, the dynamic parts are harder to format. For static query strings, formatting is worth the small overhead. For ORM-generated SQL or parameterised queries, the query is often logged and formatted for debugging.
What is the difference between formatting and optimising SQL?
Formatting changes whitespace only. Optimisation changes the query structure (adding indexes, rewriting subqueries, changing JOIN order) to improve execution performance. Format before optimising so you can see what the query actually does.
Format your SQL before committing it to source control.