
Regarding JavaScript trailing commas - erikw
http://dontkry.com/posts/code/trailing-commas.html
======
scardine
I'm a Python programmer. In Python, trailing comma are idiomatic, so I welcome
this.

Perhaps I'm just a lazy bastard, but it makes cut & paste a lot easier.

~~~
ergothus
Ditto, from the Perl side of things. I'm a JS coder for the last few years,
and I find I really hate a lot of the style conventions - they seem much more
oriented towards "because I said so" than "because it's actually better".

~~~
nostrademons
Many common JS conventions are because they were critically important at a.)
the time the lead programmer learned Javascript or b.) the time the codebase
was originally written.

Trailing commas are certainly in that category. When I started getting into JS
seriously in 2007, this wasn't a nitpick: your code would be outright _broken_
in IE6 if you had a trailing comma, and would fail with a syntax error. This
was a leading cause of IE bugs, since developers often developed in Chrome or
Firefox (which handled them fine) and it was ridiculously difficult to trace
it down.

Ditto a lot of other conventions. It was common to use innerHTML instead of
DOM manipulation because IE was ridiculously slow at DOM manipulation (React
just fixed this in their codebase _this week_ ). It was common practice to
wrap every file in a closure because all your variables would pollute the
global scope - now we have CommonJS modules and bundlers to handle this. It
was common to avoid closures in favor of prototypes & _ naming conventions
because Firebug & Chrome Devtools couldn't inspect variables in closures.

All of these are terribly obsolete now, and there's no reason to adopt them on
a new green-field project. But the point of coding conventions is uniformity
with existing code, so if you're inheriting a codebase that was written when
these were actually important, it's often good to conform just for
consistency's sake.

------
melloclello
I would argue that the trailing comma diff issue is an artefact of the fact
that diff works at the text level, not at the syntax level (I can only hope
this might be a thing someday)

~~~
ben174
Sounds like an absolute nightmare of a problem to solve. And a maintenance
nightmare.

Languages change over time.

~~~
melloclello
I would imagine any version control system attempting to solve this problem
would focus very closely on one particular language or development system. Any
pragmatic solution would also have to be a highly opinionated one.

For a related idea, see Facebook's Haskell system, in which only type-safe
code is allowed to be checked into the respository:

[https://code.facebook.com/posts/745068642270222/fighting-
spa...](https://code.facebook.com/posts/745068642270222/fighting-spam-with-
haskell/)

------
kaonashi
In some versions of IE, trailing commas add an 'undefined' element to the end
of an array.

Not sure if there are any other interpreter inconsistencies.

------
BMorearty
Oh, I see: the reasons are syntax error, diff, consistency,.

------
yisheng
_The only time you should avoid trailing commas is if your javascript needs to
run on older browsers._

If you use babel, you can write your source with trailing commas, then let the
build step remove them for older browsers.

------
kazinator
Right. Anything but _losing_ the damn commas.

    
    
       nineties {
         dude: true
         awesome: true
         rad: true
       }

~~~
mbrock
Well, that opens up a whole new can of syntax worms...

But yeah, all of this stuff just makes me more convinced that Lisp syntax is
the best ever.

~~~
naveen99
Lisp uses comas in macro evaluation, but not lists and dictionaries. Then you
have reader macros. Lisp syntax can be arbitrarily complex.

~~~
lispm
macro and comma is fully unrelated. The comma in backquote expressions is not
even limited to lists. Commas are used in backquote forms to force evaluation.

For example one can write a vector of three elements, where the second element
is computed:

    
    
        `#(1 ,(first *features*) b)
    

Backquote list forms happen to be used in some macros as a kind of template
forms. Macros can be defined without them and backquote forms are also used
elsewhere in Lisp.

~~~
kazinator
They are not "fully unrelated". The backquote syntax for constructing lists
was primarily designed for macro programming. See the paper _Evolution of
Lisp_ by Guy Steele and Peter Gabriel:

 _" Macros took a major step forward with Lisp-Machine Lisp, which
consolidated the various macro-defining techniques into two standardized
features that were adopted throughout the MacLisp community and eventually
into Common Lisp. The macro defining operator DEFMACRO provided list-structure
destructuring to arbitrary depth; the backquote feature provided a convenient
and concise pseudo-quoting facility. [ ... ] Backquote and DEFMACRO made a big
difference. This leap in expressive power, made available in a standard form,
began a new surge of language extension [...]"_ [3.3]

~~~
lispm
[http://repository.readscheme.org/ftp/papers/pepm99/bawden.pd...](http://repository.readscheme.org/ftp/papers/pepm99/bawden.pdf)

------
tigershark
In my opinion it is just a matter of personal taste, if I move some code
without trailing commas I make sure that the commas are in the right place.
This actually can be seen as an advantage given that blind copy and paste is
the source of all evils, so a syntax error will _force_ you to reconsider what
you have just done blindly. All in all I don't see a problem in using either
styles, it's only one character difference at the end.

~~~
bluejekyll
For compiled languages like Rust, you might be correct, though even there I
use trailing commas, specifically for the reason mentioned. It reduces bugs
when you add or swap around array elements.

In a compiled language you catch this because it's a syntax error. In
JavaScript, it might be missed through every code review (because it's subtle)
and and then break on release to you production system.

So it's not just style, it can help reduce bugs.

------
jchendy
I don't actually know the history of JavaScript style, but I feel like this
assertion is likely trivializing something more complex:

>The reason you were once told trailing commas are bad is because they are
invalid in EcmaScript 3.

I can imagine plenty of reasons people would have for avoiding trailing commas
even after they became valid syntax.

The whole "consistency" section also feels like unnecessary snark.

~~~
albedoa
> I can imagine plenty of reasons people would have for avoiding trailing
> commas even after they became valid syntax.

Could you list a few?

------
tikhonj
I've actually come to like a weird style popular in the Haskell world,
_leading commas_ :

    
    
        { one   = 1
        , two   = 2
        , three = 3
        }
    

It's weird, but it's actually pretty convenient. I think it has all the same
properties the article argues for, but I don't want to figure it out for sure
at the moment.

~~~
esturk
No way. What you if had to cut and paste the first item?

~~~
dllthomas
Then it's extremely obvious that it needs fixing, and your cursor is usually
right there to make the change.

It _is_ marginally more difficult than leaving in trailing commas, but way
better than adding missing unaligned commas at EOL.

------
jorgt
I tend to remove them because trailing commas break JSON. The similarities
between JS and JSON are small enough for me to get confused over it and I'd
rather remove the cause of potential errors there altogether.

------
mrspeaker
Trailing commas were tough to get used to because my primary communication
language is English,

After a while I got used to them and I like the copy-paste-ability the
enable... I'm also hoping they put an end to leading-comma style,

~~~
reustle
There is so much in programming that isn't necessarily directly in line with
English, why are trailing commas any different?

~~~
mrspeaker
This was just my opinion, and it was not based on logic: I battled through and
now I'm a happy trailing comma-er. But if I think about your question, I'd say
the answer was because commas are the only part of coding that has a strong
resemblance to written english in that you commonly use them to separate items
a list.

------
homero
Yes I like them in PHP too

------
hillsidefm
Controversies like the "trailing comma" strike me as evidence that JavaScript
has superfluous syntax. The reason it even uses commas the way it does is that
it started life as a lisp with (manager-mandated) Java-like syntax.

I happen to agree with the position that syntax that can be made implicit
should be. CoffeeScript has done a good job of this. LiveScript has done an
even better one. What are the arguments against using a syntactically cleaner
language that compiles down to the exact same features?

~~~
exception_e
> Is there a good reason not to use a syntactically cleaner language ...

I find Coffeescript hard to read. Especially when dealing with nested
callbacks (e.x.: when you have to nest, such as with Jasmine `describe` and
`it` blocks for testing).

Here's an interesting thread on the "cons" of using Coffeescript:
[https://news.ycombinator.com/item?id=6527316](https://news.ycombinator.com/item?id=6527316)

~~~
hillsidefm
Fair enough. Maybe CoffeeScript specifically isn't the answer. But the general
idea of compiling neater languages into JavaScript strikes me as a better
long-term solution than settling for its current syntactical warts, which are
entirely historical accidents.

I do like ES6!

~~~
exception_e
I agree. Language features such as async/await (ES7) are exciting.

~~~
ludamad
I am excited by async/await but it makes code non-trivially harder to debug.
The tools are far from there

