Hacker News Reader

Comment by hughes | Hacker News Reader

    {
      "name":   "Bender"
    , "hind":   "Bitable"
    , "shiny":  true
    }

Who puts commas at the start of a continuing line? What good could that possibly do?

View on HN

It lets you comment out a line without having to remove the trailing comma from the previous line. That'd be useful if JSON had comments.

I've seen people do this in the SELECT portion of SQL queries too.

Personally, I hate this.

True about the comment. That's why I like the trailing comma style in pep8[1], which enables both commented out array elements and smaller, more meaningful diffs when making additions or deletions. If only trailing commas were valid JSON!

[1] https://dev.launchpad.net/PythonStyleGuide

> It lets you comment out a line without having to remove the trailing comma from the previous line. That'd be useful if JSON had comments.

It also lets you remove the line (for the same reason that you can comment it out) without modifying other lines. This is somewhat convenient if the file is one that you are going to manually edit (and even more useful if it is going to be the subject of line-oriented diffing tools, since the only changed lines will be the ones with meaningful changes.)

I'd agree that its less readable, though.

it also let's you add a line at the end (most common case) without modifying the previous line.

If you use alphabetically ordered keys (a pretty good practice anyhow), that advantage goes away. If you just develop a habit of adding stuff to the front where semantics do not matter, that advantage goes away.

It also lets you find missing commas more easily.

I found it almost a necessity when I started generating larger DOM trees in JavaScript. No more games of hunt-the-missing-comma-on-the-ragged-edge: https://gist.github.com/insin/8e72bed793772d82ca8d (These syntax woes are one of the main problems React's JSX solves)

I think it's great when doing adhoc analysis that only you are ever going to look at, though maybe I just need a better IDE. Another neat / silly trick is to add a truthy condition at the beginning of a where:

   select * 
   from foo
   where 1=1 
     AND bar = 1
     AND baz = 2

That way you can comment out any of your conditions without breaking the syntax.

I do it in UPDATES

    UPDATE FOO
    SET BAR = 1
    ,   BAZ = 2
    ,   QUUX = 3

I like it that way. Makes it clear the relationship between the continuing lines and their parents. Just the natural extension of

    WHERE ALICE = 1
    AND BOB =2
    AND CHARLIE = 3

That seems backwards to me. I put the operator on the previous line so I know the expression has more parts coming.

In your example, I don't know SET BAR = 1 isn't the end until I read the next line.

Different strokes I guess. I've tried both ways and I've found this one pleasant for scanning down an expression.

I mean, it's kind of the SQL analogue to the

  MyObject
  .Child
  .Grandchild
  .ItsMethod(stuff)
  .HeyThatReturnedAnotherObject()
  .MoreObject(moreStuff)

> It lets you comment out a line without having to remove the trailing comma from the previous line

That would only be an advantage above comma at the end on the last line. It really only moves the problem from the last line to the first one. Now you can't comment out the first line without removing a comma...

In the comma-first method, adding a new element at the end produces a one mine diff. But when doing comma-last method, then adding a new element to the list gives a two line diff.

It can make resolving merges just a little bit easier.

If IE didn't barf on a trailing comma after the last value, we wouldn't have this problem. That's probably the biggest source of all my IE JavaScript bugs. To be fair, I'm not actually sure what the spec says, but the spec might be wrong :-)

IE9 and above should handle it fine, so it's just a matter of time before this problem goes away. In the meantime there are two things you can do: use an editor which highlights this as an error (e.g. Webstorm), or add a pre-commit hook on your code repository which disallows committing code that doesn't pass jslint checks. We use both practices on a 200 kline js codebase, and it has essentially gotten rid of javascript errors at the customer due to bad syntax (as well as those tricky = / == / === issues).

It would also make removing a line a 1-line diff instead of 2. But I still fully agree with the hate.

The comma first pattern is pretty common. I've seen it used in JavaScript (as well as JSON), SQL and Haskell; I'm sure there are others.

Some encourage this so you can comment out a line without having to add/remove commas. However, this isn't the case if you want to comment out the first line; so in effect, it just moves the problem from the bottom to the top of the list. Other proponents say it's easier to spot typos (i.e., missing commas). For example:

    var something = {
      foo: 'bar',
      abc: '123'
      quux: null,
      xyz:  456
    };

vs:

    var something = {
      foo: 'bar'
    , abc: '123'
      quux: null
    , xyz:  456
    };

In the second one, it's clearer that there's a comma missing.

Personally, I think it's ugly and, while I'm sure I've erroneously omitted commas before, they're caught by the parser. No example comes immediately to mind where missing a comma can be interpreted as something other than a parse error.

Me, it is so much better. The comma is really a particle of the next item, not the previous.

Here's an item there's going to be another one,

Here's an item

, I'm another one

That's how the amazing TJ Holowaychuk declares his imports.

https://github.com/mochajs/mocha/blob/master/lib/suite.js

You'll see it like this:

    { "name": "Bender"
    , "hind": "Bitable"
    , "shiny": true }

It makes diffs look nicer when you add and remove items

Send a pull - github for the win! http://darobin.github.io/formic/specs/json/

Reply on news.ycombinator.com