Leading commas, why?

[arjamizo]

Chapter about leading commas says its better to use trailing comma (chapter here)

In opposite, https://gist.github.com/isaacs/357981, says that it's better to use leading commas and, personally, I prefer to do so, because it's easier to add (or comment-out) lines in object definition.

What is explanation for this suggestion?

[nkbt]

That's unreadable.

[jaseemabid]

1. Its unreadable
2. It makes jslint useless

Missing commas, extra spaces, broken indentation and everything in the style category - its too hard for human eyes to catch them all, so resort to a linter for all of that.

[netpoetica]

@arjamizo This is a very common convention for Nodejs, less common in front-end JavaScript. I think the argument that it is "unreadable" is essentially opinionated nonsense, however, it does indeed break JSLint and JSHint as well. In fact the primary reason it is done is because the people who like it think it is cleaner-looking code.

isaacs is attempting in that gist to illustrate how much more visibility the missing comma error has in leading-comma style, allowing a developer to quickly see an error that will cause problems in linting/minification/interpretation. (JSHint supports this coding practice via http://www.jshint.com/docs/options/#laxcomma option)

Additionally, when you think about it, the comma is there FOR/BECAUSE OF the variable that follows it, not for the one that precedes it. Meaning, if you only have 1 variable, you do not need any comma - the comma is only necessary because of the addition of another variable, so leading a variable with it shows a clearer picture of "why is it there".

One last thing that is interesting to note is that commenting out your variables requires less modification of the code:

var a = "ape"
  , b = "bat"
  , c = "cat"
  , d = "dog"
  , e = "elf"
  , f = "fly"
  , g = "gnu"
  , h = "hat"
  //, i = "ibu"
  ;
// Did not need to move the semicolon at the end of list

// standard style
var a = "ape",
  b = "bat",
  //c = "cat",
  d = "dog",
  e = "elf",
  f = "fly",
  g = "gnu",
  h = "hat";
  //i = "ibu";

// Notice - had to put a semicolon after "hat". You also could solve this by just moving your semicolon to a newline, but then you need to delete your comma.

Personally, I do not use it because generally people are are not familiar with it. They are used to conventions in ActionScript, Java, C#.NET, C, and to them this looks "unreadable". This is one of those things that is OK in Nodejs but leads to confusion in front-end JavaScript, as generally people who are writing JS on the front-end are used to C-like syntax that is used in most example code.

[arjamizo]

@netpoetica thank you for such a detailed explanation.
When I am reading all the stuff about formatting the code I am getting to the conclusion that, since I would like to keep to what-most-people-find useful - in this case trailing comma, I should have something like pre-checkout (e.g. in git-hooks) code-formatting script which makes code most useful and readable for me, but there should be also pre-commit (also in git-hooks or dot editorconfig, created by default if using [yeoman](http://yeoman.io, at least for some "archetypes", like generator-angular) script which will keep source code in repository unified.

but I see potential issues with this auto-formatting, because sometimes I dislike being forced to use some kind of notation because some parts of code might be formatted in unusual way for better readiness.

[hshoff]

Great discussion so far! Love reading issues like this.

The truth is, I left out the answer to "why?" in the commas section because there is no real answer, it's a stylistic choice.

The important thing for you and your team is to have a Commas section. It forces you and your team to make a choice. Turn it into a binary decision where you either do trailing commas or you don't. There is no better. Just consistency.

🍻