Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

My pet hate, directly out of SQL Server Management Studio, is how their code generation places commas. It generates code like this:

  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.


Leading with commas makes it easier to refactor if you're prototyping a query. You're less likely to cause an error when removing a column from:

  SELECT 
      first
    , second
    , third
  ...
than from

  SELECT 
    first,
    second,
    third
  ...
Which becomes:

  SELECT 
    first,
    second,
  ...


At best, that may shave off a few seconds of the time needed to refactor.

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.


I spend a lot of time writing ad hoc queries for analysis. That means I don't know what columns I want, I might be switching things up from aggregates to subsets and back. That's why you'll find things like:

    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 writing


> we are used to trailing commas

Leading commas and other operators are common in some languages. Haskell, for example:

https://github.com/tibbe/haskell-style-guide/blob/master/has...


The time saving isn't as important as avoiding frustration in your tools. Stubbing your toe on silly problems like trailing commas breaks flow and makes exploring less fun.

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.


Allowing commas on the last list item makes it easier to refactor.

Leading commas just shift the problem around, making the beginning of the list hard to change, instead of the end.


Agreed.


Think of the leading commas as being the same as leading AND/OR in a where clause or a leading JOIN in a join clause. I used to prefer the commas after the column names as well, but I've since been converted to the wisdom of placing them to the front. It does take a little while to get used to it, but now I visually prefer it and find that I can read my SQL and find any potential issues much faster. Plus its much better for dynamic SQL and refactoring SQL statements.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: