7 ms·
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 t
by pielud 12y ago
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.
- hughes 12y agoTrue 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 https://dev.launchpad.net/PythonStyleGuide
- dragonwriter 12y ago> 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.
- lucio 12y agoit also let's you add a line at the end (most common case) without modifying the previous line.
- jkrems 12y agoIf 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.
- dbla 12y agoIt also lets you find missing commas more easily.
- insin 12y agoI 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 https://gist.github.com/insin/8e72bed793772d82ca8d (These syntax woes are one of the main problems React's JSX solves)
- stevepike 12y agoI 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.
- Pxtl 12y agoI 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
- dozenal 12y agoThat 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.
- Pxtl 12y agoDifferent 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)
- nkuttler 12y ago> 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...
- diroussel 12y agoIn 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.
- bobbykjack 12y agoIf 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 :-)
- Joeri 12y agoIE9 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).
- jacobr 12y agoIt would also make removing a line a 1-line diff instead of 2. But I still fully agree with the hate.