A better coding convention for lists and object literals in JavaScript

comma-first-var.js

// See comments below.

// This code sample and justification brought to you by
// Isaac Z. Schlueter, aka isaacs

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

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

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

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

// Objects:

// JSON.stringify style
var o = {
    a : "ape",
    b : "bat",
    c : "cat",
    d : "dog",
    e : "elf",
    f : "fly",
    g : "gnu",
    h : "hat",
    i : "ibu"
  },
  a = [
    [ "ape", "bat" ],
    [ "cat", "dog" ],
    [ "elf", "fly" ],
    [ "gnu", "hat" ],
    [ "ibu" ]
  ];
  

// comma-first
var o =
    { a : "ape"
    , b : "bat"
    , c : "cat"
    , d : "dog"
    , e : "elf"
    , f : "fly"
    , g : "gnu"
    , h : "hat"
    , i : "ibu"
    }
  , a = 
    [ [ "ape", "bat" ]
    , [ "cat", "dog" ]
    , [ "elf", "fly" ]
    , [ "gnu", "hat" ]
    , [ "ibu" ]
    ];

// errors in objects:

// JSON.stringify style
var o = {
    a : "ape",
    b : "bat",
    c : "cat",
    d : "dog"
    e : "elf",
    f : "fly",
    g : "gnu",
    h : "hat",
    i : "ibu"
  },
  a = [
    [ "ape", "bat" ],
    [ "cat", "dog" ],
    [ "elf", "fly" ]
    [ "gnu", "hat" ],
    [ "ibu" ]
  ];
  

// comma-first
var o =
    { a : "ape"
    , b : "bat"
    , c : "cat"
    , d : "dog"
    e : "elf"
    , f : "fly"
    , g : "gnu"
    , h : "hat"
    , i : "ibu"
    }
  , a = 
    [ [ "ape", "bat" ]
    , [ "cat", "dog" ]
    , [ "elf", "fly" ]
    [ "gnu", "hat" ]
    , [ "ibu" ]
    ];

// Addendum: effects on the return statement.
// It does not break.

return [ 1
       , 2
       , 3
       ] // returns [1,2,3]

return { a : "ape"
       , b : "bat"
       } // returns {a:"ape",b:"bat"}

// even just separating two values by commas is fine,
// though a bit silly
return 1
     , 2
     , 3
     , 4 // returns the last value, 4

// this, however is wrong:
return
    1
  , 2 // returns undefined, because of semicolon-insertion.

// so is this. otb == fail.
return
  { a : "ape"
  , b : "bat"
  } // returns undefined,
    // then creates a block with two named statements.

// this is ok:
return ( 1
       , 2
       ) // returns 2

// so is this:
return (
  { a : "ape"
  , b : "bat"
  }
) // returns {a:"ape",b:"bat"}


// Addendum 2: A function call

doSomething( aPrettyLongVariableName
           , "A string, which has some useful information"
           , "If you put these all together, it'd be too long"
           , { a: "is for antelope", b: "is for bat" }
           , 42
           )

// Addendum 3: More realistic error in standard style:

// leaks FIVE globals!
var a = "ape eat banana",
  b = "bat, allowed to fly",
  c = "cat toy",
  d = "dog chasing the mailman,"
  e = "elf lord",
  f = "fly through the air",
  g = "gnu is not unix",
  h = "hat goes on your head",
  i = "ibu isn't a cow";

// Error: Can't call method 'forEach' of undefined.
// not passing in undefined as an argument!??
mergeLists([ apple, [ penelope, granger ] ],
           [ fun ],
           [ 1, 2, 3, 4, 5, 6, 7, 8 ]
           [ "mary's store has many pies, and cookies, and eggs," ]
           [ function() { doSomething() } ]);

I can't believe people are seriously debating this and trying to use "arguments" on this topic. It makes about as much sense to debate if a painter should hold a brush in their left or right hand.

It doesn't matter

To left-handed people one answer seems more fitting while right-handed people will opt for the opposite for exactly the same reason.

Just like tabs vs. spaces, brace placement and first vs. third person narration it all boils down to personal preference.

@isaacs made an effort to explain why this particular style works for him. Well done.
Anyone who considers the title "A better coding convention ..." anything other than click-bait has a lot of growing up to do.

Really... Can we all just go back to debating which Doctor Who is better?

Tip: Beautify && Comma first, Almost No Code!

var obj = {url:"http://example.com",number:1,complex:["first",{second:"null"}]}

• Beautify, comma-last

  JSON.stringify(obj, null, 2)
  {
    "url": "http://example.com",
    "number": 1,
    "complex": [
      "first",
      {
        "second": "null"
      }
    ]
  }

• Beautify, comma-first - column start ^{("Greek style")}

  JSON.stringify(obj, null, 2).replace(/,\n /g, "\n ,")
  {
    "url": "http://example.com"
   , "number": 1
   , "objects": [
      "first"
   ,   {
        "second": "null"
      }
    ]
  }

• Beautify, comma-first - word start ^{("English style")} - Preferred.

  JSON.stringify(obj, null, 2).replace(/,\n /g, "\n ,").replace(/ *(,(\ +))/g,"$2,")
  {
    "url": "http://example.com"
   ,"number": 1
   ,"objects": [
      "first"
     ,{
        "second": "null"
      }
    ]
  }

_#Source

Yoda commas.

For nearly 16 years of our lives, we write essay after essay using commas. On top of that, we write billions of emails. With all the variables and preferences in our shared environments, shouldn't we at least adhere to our life-long habit of left-to-right comma interpretation?

In my humble opinion, I prefer reading code that isn't totally opposite our natural tendencies.

This doesn't feel natural at all, although technically it is the same text:

For nearly 16 years of our lives
, we write essay after essay using commas. On top of that
, we write billions of emails. With all the variables and preferences in our shared environments
, shouldn't we at least adhere to our life-long habit of left-to-right comma interpretation?

^{@NoelBaron, linguistically, a compound-sentence has a comma so you'll pretty much know when to halt for a breather, but on your sample text, inserting a line-break before the comma (creating a comma-first look) also implies a full-stop or a new paragraph, comma on code has no linguistics value, and one should not be looking for such. On inventing a new program-language, we might as well use pipeline, hash-tag or any other characters to separate code-blocks, which do not have analogous meaning in English language-composition thus, not creating this confusion.}

^{Most of pro-comma-first developers usually mention their lack of forgotten commas at the end of a long line of code, or even the OCD relief of same-column-straightening of characters ;)}

^{Anyway, the comma-first convention is gaining quite a lot of popularity among users lately,
I can say that software-developers at Google (Israel) are using it on most of the new projects, due to its superb readability.}

I give a star here since I discovered this place lol.

I'm using commas-first style almost since I started JS around 6 years ago now.

Guys you also missed something, commas-first is essential when you use multilines keyboard shortcut.

In VS or Sublime, CTRL + D for few entry in a JSON then END then add somehting, paste, or select a value. You don't have to deal wth the comma at the end.
Also CTRL + SHIT + TOP or DOWN in VS will make a multi-line cursor, then SHIFT + END and you selected all values excepted commas (or just select the keys, or the values, whatever).

I use this everyday everytime and each times I show this to a developer that is not using these shortcuts (and not using commas-first) he reconsider his position lol.

As a general rule, you should split your statement at the highest place possible in your syntax tree. Usually at an operator.
Since that operator is the pivot between 2 lines, it should be put prominently at the begin of the line.
Therefore the comma, or any other operator, +, &&, should start the line.

Use ternjs / eslint and get a life.
Putting the least important characters of the code up front is ridiculous.

actually, I love it and have been using it for years.
the comma on the left just looks like a bullet list.
ever since I stared using it - I never forgot a comma or struggled with braces again, even when working with nano on remote files.

but - I'm working with a team now that will agree to this style only if it will be supported by the lindter.
so - is there an eslint rule I can use to enforce this style, especially for arrays and objects?

Is there an eslint rule that will not choke when you do something like this? My eslint configuration complains about Project being indented by 2 chars.

const {
      Project
    , Dimension
    , Task
    , View
    , Layout
    , User
    , Group
    , Organization
    , CustomField
} = db.model;

It's too bad so few people use comma (and operator) first.
There are so many bad examples here.
Comma and operator first is really useful when you nest complex data structures or code.
Here is a case where it is good at:

x = {
    a : ( b + 27 * (
        foo1(
            b
        +   (   (c + 232312)
            *   (   foo2(
                        (d + 3423423 * foo34(34))
                    *   (y+3243)
                    )
                +   foo3(
                        (234 * sdf + 23 * dfdse )
                    ,   23423 + foo45(23)
                    )
                )
            *   ( 23423 / 34)
            )
        +   (   234234 / sdf + 23423)
        +   (   foo4(234234)
            /   foo5(
                    foo34(
                        (   (   fo345(3434 + 2323423)
                            +   23423
                            )
                        /   234
                        )
                    ,   [ 23234, 23432, 234234]
                    )
                /   349
                )
            )
        )
    ))
,   b : 234
,   c : [
        34534
    ,   534634
    ,   98
    ]
,   d : {
        x1 : [
            23423
        ,   232
        ,   43+343*(
                343
            +   324
            )
        ,   23
        ]
    ,   x2: 234
    ,   x3: foo(2323 + (
                ( foo56(234) + 3434)
            /   (2342 + foo6(2323))
            ))
    ,   x4: 34534
    }
}

I don't know how I got there, probably about the trailing comma debate I had with a colleague, but honestly this hurts my eyes so much. You don't do comma-first because firstly it's ugly and unintuitive. Javascript was designed like any coding language to be human-friendly. The creators knew how to read and write english, meaning that you should respect the comma position as you would in an non programming language.

Now if you write like this ,you'll see that this is by far the dumbest way to say "Hey I'm a hipster I write code with comma first" ,that's not how you're supposed to do things and you'll be the only one to do this in a team that would dare to hire you.

Comma is not a operator so I don't see the point how saying it should be the first thing in a line and in english (or any other language), a comma is attached to the previous word and a space (or a new line) must be put after this comma.

I really think I'm in the flat earth conference.

Not a chance @bhubr, some of us like our "comma-style":[2,"first"] rule ;)

The only place I've seen it cause issues is with JSDOC blocks not being identified correctly by the IDE.

A lot of the examples in this thread are using variables values of same/same character lengths. When line length is random it becomes much more obvious that comma-first adds value.

So far I've not seen a single sound argument here pro comma last. All mentioned here is just comma-first is ugly or stupid.

Those in favour of comma-first mentioned some clear advantages though.

I code comma-first as well, looking for pro comma last, as it seems lots of tools and big names favour comma last. Any objective pro comma-last arguments that I might consider?

English and code are two different things. You cannot justify coding style with English text conventions.

Or we should write in paragraphs, indent the first line, capitalize the first word and justify the rest left and right.

    X = {a : (b + 27 * (foo1(b + ((c + 232312) * (foo2 ((d +
3423423 * foo34 (34)) * (y+3243)) + foo3 ((234 * sdf + 23  * 
dfdse), 23423 + foo45 (23))) * (23423 / 34)) + (234234 / sdf
+ 23423) + (foo4 (234234)  /  foo5  (foo34  (((fo345 (3434 +
2323423)   +  23423)  /  234),  [23234,  23432,  234234])  /
349))))), b : 234, c : [34534, 534634,  98  ],  d  :  {x1  : 
[23423, 232, 43+343*(343 + 324), 23 ], x2 : 234,  x3  :  foo
(2323 + ((foo56(234) + 3434) / (2342 + foo6(2323)))),  x4  : 
34534}}.

And end with a period.

Gosh are people still having this debate in 2024??!? 😆😆😆

People, look around you, the whole industry is using Prettier and nobody cares about this nonsense. It's not 2010 anymore

@happyteque actually surprisingly its still relevant, no matter which language you use.I don't code in JS much anymore, but it's honestly sad this style isn't more prevalent, for one reason: git commits.

Commas are just noise - if you add a line, they are the reason you have two lines changed, not one, or you have random lines added in the middle of your array.

As for reading code, you can go screw your eyeballs and your dipshit opinions both - nobody reads code anymore, and it barely makes a difference. You are just an intolerant twat if you can't stand the difference. Grow the f* up. Everyone else did.

If "growing up" involves insulting strangers on the internets over something as petty as this, no, i'd rather not

Everything alright bro?

@happyteque Nah that part wasn't directed at you.

There are some individuals from ~2019 I'm more responding too, that seem to have had some pretty trash opinions.

"Growing up" means accepting that, normally, this stuff isn't important. And caring about objective stuff, not trash like your arrays looking you want them to.

@bhubr

"So if you want a single reason why not to use this crap, here it is: no one in his right mind does it, and no one wants to hear your explanation about why it's so brilliant,"

Touche. Maybe you should follow your own advice, lol.

So far I've not seen a single sound argument here pro comma last

@KoJaMan Lack of reading comprehension and/or willful ignorance does not an argument make.

The only comment you really need to read about this is mine, right here.

Good day.

@KoJaMan
@waynebloss

"Whoever said "use better tools" was right. (And there is a wrong here.)"

Partially correct.

As you said, the commas should really disappear, what we are really after are record separators not commas. I couldn't give a flyint hoot what you use, as long as my tooling can differentiate.

The tooling should be handling the job of presentation.

I suppose you could argue the git tooling could also be better, but two wrongs do not make a right. Building one tool to format everything wrong and another to hide that mistake is wasteful.

Besides, what happens when you want to see the commas? (For various reasons in different languages). Crying that your bad tool is prevalent is not a good reason to continue using bad tooling and bad formatting...

Which brings us to the real truth - there is just a lot of crappy code and crappy tooling that's prevalent. You learn to deal with it.

Thats being said, there are objective reasons to not promulgate the mess. Is this an issue I particularly care about? No. But I do care about people pretending its a settled issue instead of a papered over problem. It takes time, but we can always fix things (maybe in a thousand years?)

@waynebloss That comment mostly claims in a dramatic way that you dislike comma-first very much, and implies it is stupid. If it is about "punctuation should disappear", well, I disagree. When I see a new line I like to know why. I don't want to assume that there is probably a comma at the end of the previous line. I can navigate a complex expression faster if the delimiters, the symbols giving structure to the expression, are at the left. People work in different ways I guess.

I couldn't unsubscribe earlier because the mobile UI doesn't have that button. Finally I'm at my desk and can unsubscribe from this inane conversation. You people are crazy. This is all so utterly pointless.

"People work in different ways I guess."

Huzzah for someone who gets it, lol.

@fischerflorian
@waynebloss
@KoJaMan

To be clear, I do think punctuation is important.

This is one reason the prior comma format is (better charactersets non-withstanding), plainly superior.

How that is represented is of course partially up to the tooling, however the plain format having built in recognizable record delimiters is more graceful than relying on your IDE. The folks this bothers could easily move the comma to the end as a matter of visual representation.

The claim this doesn't matter is entirely stupid and shortsighted.

In the realm of civics and politics, paradoxically, the irrational choice is often the rational choice.

The rational reason to use comma-last formatting is the prevalence of irrational reasons for using comma-last formatting. Those unreasonable reasons are very widespread, and encoded in tools and expectations and other peoples' behaviors. You can scream from the mountaintops (or from the comment section of a gist that's old enough to be in high school at this point), but you'll probably never boil that ocean.

So go along get along, do the thing that is objectively worse, because in context, it is objectively better.

In the realm of civics and politics, paradoxically, the irrational choice is often the rational choice.

Which is why I barely care about this/think it will take thousands of years to fix (possibly).

The fun thing about civics and politics, are, that the winds do change from time to time. We can wear the fashions of the day and still be keepers of the truth(s).

It is never wrong to want to know the most objective truth, even if you will not today follow it, @isaacs .

I wish I was better at distinguishing AI so I could really understand whether this is humans waisting each others time, or computers doing an elaborate dance of bits.

Also, I think my comment of almost ten years ago has aged well...

Arguments like "if you think X you need to grow up" are just dismissive and not constructive.

When you say "@isaacs made an effort to explain why this particular style works for him."

• "made an effort to explain" suggests he didn't really explain.
• "works for him" (with emphasis on "him") suggests he is the only person to think like that.

No, isaacs explained why this style is preferred by him and a bunch of other people.

And "Can we all just go back to debating which Doctor Who is better?" is yet another appeal to ridicule. As actually your whole post is.

I don't think this comment needed to be repeated.