[harterrt]

For comparison, here’s Mozilla’s SQL style guide: https://docs.telemetry.mozilla.org/concepts/sql_style

[hnlmorg]

This is a much better style guide in my opinion.

It’s still highly readable but also much much easier to write and modify.

Though I am biased because it’s also how I used to write SQL back when PL/SQL was my day job. Albeit I fell into this design because it proved to be the easiest way to write and maintain readable code.

[yen223]

Thanks for sharing this!

It looks so much cleaner in my eyes.

Plus it uses constant-sized indents, which means less futzing about with spaces and all that.

Also means you can comment out the first select item, something you can't do with the article's approach.

[harterrt]

Yes! I can’t see the point of enforcing fussing with indents to get a river.

[cwbriscoe]

I am definitely not a fan of that style. Wastes too much vertical space without much benefit.

[mjevans]

The benefit is how quickly an experienced programmer can accurately isolate portions of logic and understand / mutate them.

It also achieves that in monochrome, which is likely to be the case when an SQL query is in a shell script's <<< HEREDOC or in a string blob in a log file or source code for another language's compiler.

[harterrt]

What would you change?

[seer]

I think this guide misses the point that “JOIN” is not a root keyword but a modification on “FROM”. It is more akin to logical “AND”, “OR”, etc.

And this stacks much better once you start doing complex joins especially when you can add parentheses to change where you actually join

    FROM a JOIN b JOIN c

Can be different than

    FROM a JOIN (b JOIN C)

Apart from that I think I came up independently to the exact same rules when building the prettier extension for SQL a few years back.

[steve_gh]

SQLis based on set theory, which is asdociative. So (a JOIN b) JOIN c = a JOIN (b JOIN c)

Your DB's query planner should optimise given the available indices.