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() } ]);

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.

@Potherca "I wish I was better at distinguishing AI" lol real concern. But nope I'm real... (maybe a bit bored and this landed top in my inbox for whatever reason - that was probably an AI's doing).

I agree with @fischerflorian, your whole post remains as ridiculous as it was 10 years ago, and is wrong to boot:

"It makes about as much sense to debate if a painter should hold a brush in their left or right hand."

Yes, actually, it turns out some people are left handed. So, actually, it does matter for people, since they have different ways of working.

That doesn't mean some of the other points aren't untrue; but people with disabilities etc. find it much harder to exist in an intolerant, dismissive society. Which, TBH, a lot of folk here seem to be some flavor of.

On top of that, its not actually clickbait, if there are objective reasons this is better. Balanced by, how much of a gain will someone get from following this today:

• Start your own project and enforce this rule - good job! Well you probably pissed some people off. You can't make everyone happy.
• Existing project with opposite rule - probably not worth starting a fight over. But might be worth seeing if people are willing to switch. There are mostly only positives.

@fischerflorian The sentence "made an effort to explain" is meant to congratulate the author on actually making an effort, as in, taking the time and energy to define and explain why comma-first can be superior to conventional comma notation. It is not meant as dismissive. I am sorry my intent is not clear, and that you should read that into such a sumple statement.

The same goes for "works for him" (with emphasis on "him") which is to emphasise that this is something that works for the author (inclusive) rather than only for them (exclsive)

Regarding:

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.

As the actual author of the post, and thus being aware of my own intent, I can assure you my intent is not to ridicule, but to assert the opinion that, where the actual use of comma-first notation has merit, the mostly repetitive discusion about it does not hold any merit.

In response to

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

I don't think any of the points made in previous comments need repeating. In fact, I think that almost the entire comment thread can be deleted without much loss to humanity as a whole, but regardless of our opinions, here we are.

I do feel you might be trying to read my comment as negative on purpose. Please note, nowhere do I state that I disagree with the author. Just with people who seriously feel this is a viewpoint that needs to be either defended or attacked. It is neither wrong nor right. There are no sides. It either works for people or not. Debating it as if there is some rational to this that works for everyone is just another thinly veiled semi-religious timewaster.

---

@smaudet Good to hear! Human here too.

Yes, actually, it turns out some people are left handed. So, actually, it does matter for people, since they have different ways of working.

That's more or less my point. Some people are left-handed. Correct. But how much discussion do we have about that fact? Remember educational history, when people were not allowed to be right handed? Much misery ensued. Discussing the fact whether left-handed people should be left-handed or not is senseless. Some people are left-handed. End of debate. For me, comma-first falls under the same no-brainer. Some people prefer it. Let them. It comes down to wiring more than preference. Why discuss it (at length)?

people with disabilities etc. find it much harder to exist in an intolerant, dismissive society.
Which, TBH, a lot of folk here seem to be some flavor of.

That I agree with wholeheartedly. That was (and is) also the reason for me to complain in general about the state of comments and their tone.

Regarding whether the title "A better coding convention for lists and object literals in JavaScript" is clickbait or not... To me it is. It doesn't say what the improvement is (comma-first) so I have to click a link to go here and read it. That signals clickbait to me. But hey, opinions, right?

I've used the comma-first notation for years, even before my original comment. Not even just in JS but also PHP projects. I've never had much complaint or trouble. Most folks I worked with didn't need any convincing. They saw the merit immediatly.

For the last five to seven years, I've not used it at all. Everyone just uses an editor or IDE and fixes the squigly red marks that appear when comma's go awry. At this point I no longer have a preference... But I still think it is silly discusssing the topic at this length.

Not that I am above sillyness myself 😼

Reading back the comment, my current favorite is:

If the IDE can tell where commas ought to be, why doesn't it just put them there? Why the red flag dance?

As in 2024, GitHub Co-Pilot does precisely that. How far we have come... 🥲

@Potherca

Why discuss it (at length)?

Three reasons.

1. Death by a thousand papercuts.

Its easy to overlook small, mostly-insignificant things.

But as time goes on, they build up, entire ecosystems begin to devote themselves to "solutions" to paper over them (ever seen a system library whose point is to resolve path character differences? There are just two that I know about, but arguably hundreds of lines of code that "fix" this issue). Or, there are many, many small things, so while you have one fix for one thing, now you have 1000 fixes for 1000 things. This is not a sustainable solution, better to actually solve problems than simply work around them.

Now, of course, you perform triage - of those 1000 issues, which are the biggest/most impactful? Fix those first. But, this is an issue that likely covers millions of lines of code, already, the impact is actually bigger than it appears.

2. Correctness and graceful degradation.

This is relatively small issue for the user - and today we have some nice tools that (mostly) obviate the need to care too much about this. I don't entirely begrudge you your reading preference, although I do think its largely silly and not something you are probably often doing.

But the two objective reasons to never use comma-last, are:

• Line diffing tools - git etc. display more noise. As said, you could write more code to paper over this issue, and then deal with all bugs/edge-cases/special unforeseen problems.
• Parsing (human and tool). Again, a situation where what you want is <record><record-separator><record>, and what you have is <record><carriage-return?><line-feed><record-separator><record>. Obviously not impossible to work around, but splitting on record separators is both faster and simpler. And for the human eye, unless we start all right-aligning our code (different discussion/issue), we want to see there are 3 records, not that there are 3 lines. One line can be off to the right, and the next line may be a continuation, or the line can contain two records, you may not be able to auto-format due to line length, etc. Screen size is not an acceptable solution either, if you have hundreds of files or windows open, you can't rely on your super big monitor (another case of code, in this case hardware, being built to solve a seemingly small problem) either.

This is the portion of tech debt.

The format you get to see, sure, our editors can be smart. I'm not saying that's a bad thing. But when your editor dies (corrupted, disk lost, copilot subscription link gone, etc), one format remains simply legible, with something simple like "split" command, or as a basic text file (think Notepad or ed level).

So no, I don't think its appropriate or helpful to look at the year and go "lol in 2024, with these tools". That's an nonconstructive, small-minded attitude.

3. Love letter to the future

I'm not crazy - I don't believe we'll fix this any time soon, probably not in my lifetime nor in a couple generations.

Now, is it useful to have this discussion here, on github comments, probably not (that's probably up to github to decide how they want to handle longevity). But hopefully someone or something will mirror this discussion, and maybe, someone in the future will be like "hey, yeah, the way we do things is kinda stupid, lets fix it!"

Here's to fixes in the future.

But hopefully someone or something will mirror this discussion, and maybe, someone in the future will be like "hey, yeah, the way we do things is kinda stupid, lets fix it!"

I am an American. We use the imperial measurement system, drive on the right side of the road, overpay for objectively bad health care, force people to live on the street rather than build houses, value our guns more than our children, and treat any attempt at public health protection as the worst form of oppression.

So, idk, I'm kind of cynical. "Objectively better" isn't just not a compelling reason to do anything, by all observations, it seems to be negatively correlated with what we actually do.

@isaacs Cynicism isn't bad, but this goes back to societies... they can and do change, and not always for the better.

I think its important not to be cynical in your approach, even if you are cynical in your outlook. Someone has to advocate for things getting better... or you'll just slide into decay and eventual collapse. Some might argue that's where the USA has been headed, so who knows? A lot can happen in a thousand years, even 100. Who knew the British Empire was on the verge of collapse at the turn of the 19th century?

Anyways I think you stopped talking about commas a while ago and we have devolved into politics. I will bow out of this part of the discussion. :)

OMG. What a fun read.

@isaacs, @Potherca, @smaudet, @Mcfloy, @fischerflorian @happyteque, @KoJaMan, @waynebloss, @alanosman, @sophana, @bhubr, @alystair

I personally think you are all awsome. As awsome as humanly can be.

Did you know?

~99% chance that the keyboard in front of you is not optimal. Because 99% of the keyboards use the QUERTY layout.

There are keyboard layouts that make typing superiorly faster. And that's true for physical keyboard and touch screens.
But they are adopted by less than 1% of the population - at least in my circles (google dvorak or colemak to learn more).

Commas

An important distinction between keyboard layout and code style is that I don't want anybody else sitting on my keyboard, but I do want people to collaborate with me in my code.

I said before - I'm a comma-1st fan, I think it looks like a bullet list, it solves the trailing-comma debate better than anything we had to make the language put up with, and many more reasons. And I know I'm the minority in that.

Over the years the only practical case against it is - when you copy snippets of it to the REPL the shell does not expect another line and breaks. You have to wrap it with {} or something to force the REPL wait. But then again. REPL users are also a minority.

The discussion started when auto-format was in its infancy. Now, autoformat is prevalent.

The point of all this...

At least for me - this was a fun read. This discussion does stimulate some aesthetic urge in my brain, and I can see that for other people as well.

Certainly, tooling changed the scene. A lot.
What used to be an advantageous sharp edge of mine - a keen eye for formatting and reflexes around styling that aid human proofing - has become a liability. I had to adapt.
But still...

The Future

On one side, one can claim that now that we have strong autoformatters and linters we don't need to meticulously not-for-get-a-comma.
On the other hand - fixing all the commas in your codebase is changing a rule and running your formatter...

Well. We could go "woke", and explain to everybody why "coma last" hurts our feelings because it is discriminatory, or bigot, or racist, or something, and tie it to the war in Ukraine and/or Gaza, ... or explain why formatters are facists tools of the kremlin design to deprive you of creativity, yea. Good luck with that. Whoo.. <...shivers> 🤦‍♂️ (I actually shocked myself. How's that for scynisicm, @isaacs ?)

. . .

So I don't know. Maybe we'll hear more of this.

Until then, stay awsome, stay human, and be respectful.
Evidently, this is also a styling rule that makes things more readable... 😜

I joined this conversation hoping to discover a compelling reason to use trailing commas in code. While I haven't found one yet, I appreciate @osher's summary.
@waynebloss I believe there's at least 1 good reason we need a separator in code and that is to be able to separate items without being forced to place those items on a new line.
Me and my team will continue using comma first. In my opinion we use tools like formatters, linters etc to make code more readable and more manageable and not just to format in a standard manner.

On a separate note, I've observed that sometimes in technical discussions, those who disagree might resort to ridicule instead of providing constructive arguments.

And finally: I fully agree with @osher:
"...stay awesome, stay human, and be respectful.
Evidently, this is also a styling rule that makes things more readable... 😜"