4 ms·

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

cwbriscoe 2y ago
I am definitely not a fan of that style. Wastes too much vertical space without much benefit.
- mjevans 2y ago
  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 2y ago
  What would you change?
yen223 2y ago
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 2y ago
  Yes! I can’t see the point of enforcing fussing with indents to get a river.
seer 2y ago
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 2y ago
  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.
hnlmorg 2y ago
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.

cwbriscoe 2y ago

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

mjevans 2y ago
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 2y ago
What would you change?

yen223 2y ago

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 2y ago
Yes! I can’t see the point of enforcing fussing with indents to get a river.

seer 2y ago

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 2y ago
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.

hnlmorg 2y ago

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.