The "readability" section has 3 examples.
The first 2 are literally sacrificing readability so it's easier to write, and the last has an unreadable abomination that indenting is really not doing much.
The leading comma format brings benefits beyond readability. For example, in version control systems the single-argument-per-line-with-leading-comma format turns any change to those arguments as a one-line diff.
I think developers spend as much time looking at commit historyas they do to the actual source code.
I think you failed to understand what I wrote.
Leading comma ensures one line diffs, but trailing comma forces two-line diffs when you add a trailing argument. With trailing comma, you need to touch the last line to add a comma, and then add the new argument in the line below.
We are not discussing bundling all arguments in a single line. I don't know where you got that idea from.
It only makes the diff clearer if you don’t have single character highlighting in your diff tool. Which most have now. Have had for a decade.
Also it’s not going to be a single line anyway. You add a line to the query and one to the caller. At a minimum. So you’re really arguing for three versus four. Which is false economy.
Because it makes the diff clearer.
Are you even reading the posts you're replying to?
It does not. It just moves the edge case to a different position: trailing comma has the "issue" when adding an argument to the end of the list while leading comma has it when adding an argument to the beginning.
Also, as pointed out by the other commenter, any decent modern diff tool will make it obvious that the change to the existing line is just the addition of a comma, which makes the difference basically moot.
I've seen them enough to not be bothered by them any more.
I also _understand_ why they exist. It's simple: It makes code marginally easier to write.
But writing confusing, unintuitive and honestly plain ugly code. Just so you can save a second after clicking run and the compiler tells you the mistake is a bad reason.
I've done plenty of SQL, and I've regularly run in to the "fuck about with fucking trailing commas until it's valid syntax"-problem. It's a very reasonable convention to have.
What should really happen is that the SQL standard should allow trailing commas:
select
a,
b,
from t;Yes. Typically shared sense of "readability" in a community for language X translates to "idiomatic patterns when writing X". There's no real thing as readability in a universal sense. It's a placeholder statement for "it's easier for ME to understand", double emphasis on "ME". Within a community, "readability" standards are merely channeling the idiomatic patterns within that community as for most members they'll be easier for the person to understand as it's what they're used to seeing.
Closer to more seriously: which "beautifier" button is best? Is there a free one that is close to industry standard?
Heard there is a faster one called sqruff, but I have not tried it
https://www.quary.dev/blog/sqruff-launch
Might also be able to cajole sqlglot into being a formatter but it's designed for forgiving dialect conversion, not formatting
? I don’t see any problems
, or anything wrong with it
.
NOBODY CHECKS LONG LINES IN CODE REVIEWS. That was the biggest problem with AngularJS. People mishandling merges and breaking everything because the eyes start to glaze over at column 90. I’ve been on more than half a dozen teams with CRs and it’s always the same. I’m exquisitely aware of this and try not to do it, and I still fuck it up half as often as the next person.
Split your shit up. Especially when trying to set an example for others.
SQL, unfortunately, is very verbose and has a strange mix of super-high and very low abstraction. There is also no SQL formatter out there that does a decent job, and no real consensus about how good SQL is supposed to look.
If I look at the 'indent' guideline, it contains e.g.:
, IFF(DATEDIFF(DAY, timeslot_date, CURRENT_DATE()) >= 29,
LAG(overnight_fta_share, 2) OVER (PARTITION BY timeslot_date, timeslot_channel ORDER BY timeslot_activity),
NULL) AS C28_fta_share
Please point me to the objective measurement of readability that you're using.
Appeals to "readability", for instance both what the OP and yourself are doing, are always 100% subjective.
On point 3: What I do is use CTEs to create intermediate columns (with good names) and then a final one creating the final column. It's way more readable.
```sql
with intermediate as (
select
DATEDIFF(DAY, timeslot_date, CURRENT_DATE()) > 7 as days_7_difference,
DATEDIFF(DAY, timeslot_date, CURRENT_DATE()) >= 29 as days_29_difference,
LAG(overnight_fta_share, 1) OVER (PARTITION BY timeslot_date, timeslot_channel ORDER BY timeslot_activity) as overnight_fta_share_1_lag,
LAG(overnight_fta_share, 2) OVER (PARTITION BY timeslot_date, timeslot_channel ORDER BY timeslot_activity)as overnight_fta_share_2_lag
select
iff(days_7_difference, overnight_fta_share_1_lag, null) as C7_fta_share,
iff(days_29_difference, overnight_fta_share_2_lag, null) as C28_fta_share
And I agree, I should have used CTEs for this query, I was just trying to save lines of code which had the unintended consequence of quite an ugly query. However I did want to use it as an example of indentation being useful to make it slightly easier to read. Although perhaps I'm the only one who thinks so.
I greatly appreciate the constructive criticism.
This is a pretty solid reason for use in temporary queries so no doubt this approach will be around for a long time.
I apologize in advance and hope you are able to come to grips with how easy it is to read and understand at some point in the near future.