# Writing more legible SQL

DevFeed: [Writing more legible SQL](<https://devfeed.tech/articles/writing-more-legible-sql-41186.md>)

Original publisher: [Read original article](<https://www.craigkerstiens.com/2016/01/08/Writing-more-legible-SQL/>)

Author: Map

Published: 2016-01-08T20:55:56Z

Content type: tutorial

Language: en

Sources: [Craig Kerstiens](<https://devfeed.tech/sources/craig-kerstiens.md>)

Topics: [SQL](<https://devfeed.tech/topics/sql.md>), [formatting](<https://devfeed.tech/topics/formatting.md>), [Code](<https://devfeed.tech/topics/code.md>), [standard](<https://devfeed.tech/topics/standard.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [formatting](<https://devfeed.tech/tags/formatting.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>), [sql](<https://devfeed.tech/tags/sql.md>), [standard](<https://devfeed.tech/tags/standard.md>)

## AI overview

The article recommends formatting SQL for readability and maintainability. Its suggestions include putting one column, table, or join per line; aligning projections and conditions; using explicit column names in grouping and ordering; commenting queries; adopting consistent keyword casing; and using CTEs to make complex queries easier to reason about.

## Source excerpt

A number of times in a crowd I've asked how many people enjoy writing SQL, and often there's a person or two. The follow up is how many people enjoy reading other people's SQL and that's unanimously 0. The reason for this is that so many people write bad SQL. It's not that it doesn't do the job, it's just that people don't tend to treat SQL the same as other languages and don't follow strong code formatting guidelines. So, of course here's some of my own recommendations on how to make SQL more readable. One thing per line Only put a single column/table/join per line. This is going to make for slightly more verbose SQL, but it will be easier to read and edit.. Here's a basic example: SELECT foo, bar FROM baz Align your projections and conditions You can somewhat see this in the above with foo and bar being on the same line. This is reasonably common for columns you're selecting, but it's not applied as often in AND or GROUP BY clauses. As you can see there is a difference though between: SELECT foo, bar FROM baz WHERE foo > 3 AND bar = 'craig.kerstiens@gmail.com' And a cleaner version: SELECT foo, bar FROM baz WHERE foo > 3 AND bar = 'craig.kerstiens@gmail.com' Use column names when grouping/ordering This is personally an awful habit of mine, but it is extremely convenient to just order by the column number. In the above query we could just ORDER BY 1. This is especially easy when column 1 may be something like SUM(foo). However, ensuring you explicitly ORDER BY SUM(foo) will help limit any misunderstanding of the data. Comments You comment your code all the time, yet so few seem to comment their queries. A simple -- allows you to inline a comment, perhaps where there's some oddities to what you're joining or just anywhere it may need clarification. You can of course go much further, but at least some basic level of commenting should be required. Casing As highlighted in these examples, having a standard for how you case your queries is especially handy. Sticking wit