select
columnA
,columnB
,columnC
from
tableName
Whereas I want my commas AFTER the column names on the same line: select
columnA,
columnB,
columnC
from
tableName
Or just looks so much neater. select
columnA
,columnB
,columnC
from
tableName
Whereas I want my commas AFTER the column names on the same line: select
columnA,
columnB,
columnC
from
tableName
Or just looks so much neater. SELECT
first
, second
, third
...
than from SELECT
first,
second,
third
...
Which becomes: SELECT
first,
second,
...The trade-off is code that is harder to mentally parse, because we are used to trailing commas, not leading commas.
If you spend more time reading code than writing it (which I assume applies to the majority of development), then the trailing comma is a much, much better choice of style.
WHERE 1=1
AND a.id = 12
--AND a.Col1 > 23
AND a.Col1 = 23
Similarly the leading comma makes it faster to cut out things I'm not using anymore. Now obviously for production code you could argue my reasons are no longer valid - but probably they'll leak through because that's what all my shk hotkeys generate and I'm used to writingLeading commas and other operators are common in some languages. Haskell, for example:
https://github.com/tibbe/haskell-style-guide/blob/master/has...
In my experience, these commas don't add any real meaning to the human readers. Will it really obfuscate the code for a future reader? I can imagine it can look unfamiliar and consequentially grate someone's nerves. Reminds me of the arguments around R's "<-" vs "=".
I agree with the sentiment for most code, but I doubt I spend as much time reading my SQL queries as I spend writing and refactoring.
Leading commas just shift the problem around, making the beginning of the list hard to change, instead of the end.