Unless you're editing actual fucking JSON and not a JS object, do this:
{
name: 'John Doe',
phone_number: '12345',
}

Not this:
{
name: 'John Doe',
phone_number: '12345'
}

Note the presence or lack of a comma after the last field. In this way, when you add a new field, you only have one line change in version control, because otherwise you'd have to add that no-longer-last comma and thus make two line changes. Not to mention you can forget to add it and spend some time figuring out what is wrong.

I do it this way :

{
name: 'Jhon Doe'
, phone_number: '123456'
}

@We3D maniac! I do that for initializers on c++ classes.

You sound like one of those "perfectionist" devs who want every minute detail to their liking.

You find yourself yelling at your coworkers a lot, don't you?

The fact that there are devs willing to accept ugly as fuck leading commas and reject optional trailing commas, deeply disturbs me.

@We3D I want to add a field before the first one.
Where is your god now?

git diff won't tell me how I should code

@Lensflare you add it as the second one ;)

@SidTheITGuy not really, calm down lol

@nururururu You do have the traits, I can read between the lines better than you know.

@cafecortado okay, based

But it should also make code review ever so slightly smoother

The second is invalid JSON.

It will not be parsable.

So don't do it, unless you're stupid.

Golang forces you to do it lol

@IntrusionCM I specifically said "unless you're doing JSON" lol

I reckon both are invalid JSON since the keys aren't surrounded with double quotes. These are examples of JavaScript objects in JavaScript code, not JSON.

@nururururu pardon me. Have a pancake.

My brain decided to ignore all relevant words, cause why bother.

🥞🥞🥞🥞🥞🥞🥞🥞

@IntrusionCM lol, it's okay, it happens to all of us

Thank you for the pancakes, by the way!

Counter point: that's ugly as fuck, the diff being 2 lines instead of one makes perfect sense, and if you can't figure out that you're missing a comma, you're stupid as fuck.

@AlgoRythm I don't think it's ugly, and from a semantic (?) standpoint it kinda makes sense, there's nothing special about the last field being the last field, so it should syntactically look the same as the other fields

@nururururu you'd never end a sentence like this,

@AlgoRythm a sentence has the inherent notion of a sequence of words in an ordering, without which it can lose all meaning (languages where the meaning of a sentence doesn't break that way still have the same structure at a sub-sentence level).

A JavaScript object contains a listing of values in no particular order, it's the same object regardless of what order you use to list its fields, and you will get bugs if you rely on that ordering. In a sense, it's the opening and closing braces of a JS object which have the same syntactic meaning as an uppercase letter and a period have, morphologically, in a natural language sentence.

You could argue that the final trailing comma should be omitted in an array, to convey the meaning of a "last" element, but that property is clearly visible with the closing square bracket right next to the last value.

Upvoting. Not because I agree or disagree, but because I want to see more people fight about a comma.

DevRant proudly presents...

After the traumatizing events of tabs vs spaces with the climax of indenting by only 2 spaces for the fun of it...

Followed by shitty shit master, the one and only Golgothan b2plane....

We bring you the fresh war on how to end an object notation: comma... Empty space... Tab... Or maybe even a nul terminator for the hardcore ones?

Get ready to rumble....

(Yeah the drugs are kicking in... And ITS gooooooooooooood)

@Lensflare "deeply disturbs me."

Every day we grow further and further from the light of burning our enemies at the stake.

@We3D chaotic evil. I like you

@Wisecrack Nah, it will make a comeback this year.

@Demolishun I'll grab the marshmallows.

I don’t think this is a better practice. If you want to gain the benefit of a couple lines removed from your diff, but meanwhile potentially setting yourself up for invalid JSON errors, I don’t think the trade off is worth it. I have experienced this in the past working with various external services, it’s not worth the risk. Also https://www.json.org/json-en.html mentions that property/values should be separated with commas and always notates that commas come ~before~ the property/value parsing, so the specs say differently too 🤔

@chonky-quiche I’d just like to highlight that I mean objects in JavaScript code, not JavaScript Object Notation which is a separate language

@nururururu but why should we write them in a different way when we can use my method for all?

@nururururu I thought u said JSON? I’m confused

@We3D exactly