I'm always amazed to see the zeal with which some database programmers format their SQL code. SQL, of course, sees no meaning or significance in whitespace so, unlike languages like Python, it allows you the choice and freedom to be as absurd as you wish in the way you layout your code. I've yet to find two SQL programmers who are prepared to agree on how SQL code should be formatted.

I'm one of the grey-muzzled SQL Coders who prefer just the occasional discreet couple of spaces to indicate subordinate clauses in an expression, but there are some programmers who insist on spraying their SQL all over the page. It becomes less like text and more like a table.

SQL was intended to be a declarative 4GL language, where queries described what was wanted in the result rather how to get the results procedurally. In a sense, it was close to a natural language. Written language, as text, isn't formatted in columns preceded with commas, for example. Sure, we have bullet points in moderation, but in general we write in such a way that indentation and formatting has little semantic significance.

With SQL code, by contrast, we might start by deciding that we want all T-SQL reserved words to be in uppercase, and do our user-defined object names such as tables and columns in camel case, with the first letter capitalized. It isn't strictly necessary unless you choose to make your database case-sensitive for some reason. By putting the T-SQL reserved words in upper case, it helps when reading code quickly, because it is, otherwise, easy to miss out the start of subordinate clauses starting with keywords such as FROM, ON, GROUP BY, INNER JOIN and so on. We may choose to put these subordinate clauses on a new line, though this can look a bit daft in a very simple SELECT clause. Having done this, it is easy to fall prey to the urge to revert to the old days of procedural languages and indent lines accordingly.

From then onwards, there is a temptation to do all sorts of formatting to make things line up and structured. How do you handle code blocks? How should subqueries, or expressions be formatted? It can all get surprisingly complicated.

After a certain point, the time it takes to do all this formatting slows productivity significantly. The task is an obvious candidate for automation, and there are plenty of SQL code-formatters around. These formatters need to accommodate a wide variety of preferences in laying out SQL. They also have to be able to format code to a variety of corporate or organizational standards.

I like molding SQL layout to my own preferences but should we have enforced 'standard' layouts to writing SQL, or do we allow written SQL to reflect the person who originally wrote the code?

Phil Factor.