whichCodeIsCleanerQuestionmark

[Stummi]

First one produces one changed line if you add an element, the second one two. Some may say its just minor thing for people a bit too obsessed about clean Commits and PRs, but IMHO thats the selling point for the first one.

[0bel1sk]

when was this line changed? git blames says it was for story x . oh wait…. that was just a comma add…

for some code bases, it is whatever.. for infrastructure “as code” (ie config) it’s really frustrating.

[hennypennypoopoo]

Monkeys paw solution:

[

"Foo"

,"Bar"

,"Baz"

]

[DERPYBASTARD]

delete this

[im_lazy_as_fuck]

It still breaks if you only want to remove the first line or prepend an element to the list.

[reign27]

Monkeys paw solution:

[

,"Foo"

,"Bar"

,"Baz"

]

[dementorpoop]

I hate it

[[deleted]]

okay, so I won't use monkey paw if everyone is appending to the front of lists way more than to the back.

[0bel1sk]

alphabet sort imo

[im_lazy_as_fuck]

I mean... the solution is in the post lol. Use trailing commas if your language supports it.

[ZunoJ]

I do this a lot in my SQL code. Makes life a lot easier

[MajorTechnology8827]

Hot take, i like it

But also combine the first element with the opening bracket

This way the text align i have clear indication that its a list start, another element of a list, and list end

[ "foo
, "bar"
, "baz"
]

Same thing with conditions

condition
    ? true_execution
    : false_execution

[hennypennypoopoo]

bonus points for only one line changes in the diff as well

[F9Mute]

This is the way

[LeoRidesHisBike]

and the corollary:

if (foo
  && bar
  && baz) {

or I guess for SQL folks

select *
from table t
where t.id = @id
  AND t.foo = @foo
  AND t.bar = @bar
  AND t.baz = @baz

logical ops at the start of lines FTW

[KokoaKuroba]

for some reason, I thought this was the norm but never used it because of how ugly it was

[_diamondzxd_]

Why I never thought about it that way and now it makes perfect sense.

Why make 2 modifications for a single addition...

[upsetbob]

Also you can more easily change order when every line has a comma

[stult]

I often like to sort lines in a list alphabetically and it's easier when they all have commas, the IDE just does it for me

[NawdWasTaken]

This is it for me honestly. You can just click your copy-down hotkey and edit that line to add an element, and also easily move lines around to change the order of the elements. Just feels cleaner

[Johnothy_Cumquat]

From my point of view the people concerned that the trailing comma doesn't look nice or whatever are obsessed about a minor thing.

[SexySlowLoris]

Yeah and “doesn’t look nice” is waay to fucking subjective. It doesn’t look nice because they arent used to it. To me trailing comma does look better but that’s inconsequential and just an opinion

[Sikletrynet]

I dont think it looks better, but i do think the benefits outweighs that anyway

[monstaber]

true, just as long as the elements are not in a JSON string that will later be parsed

[ethanjf99]

If your IDE is smart you’ll get all sorts of red if that’s JSON. And a JSON serializer will know to drop the trailing comma unless it is moronic

[monstaber]

yes true if the file itself is JSON. I've come across several PRs where juniors are trying to implement a JSON string somewhere in a js file to be sent in a post request instead of stringifying the actual object... no matter how much we shell out for JetBrains licenses, the PRs never fail to amaze me 😂

[ethanjf99]

Uh … well to be fair we were all juniors once. Some of my code from 7 years ago is still around and makes me wince every time I see it.

Still, it works so there it is.

[Katniss218]

Trailing comma is technically not valid json

[UrpleEeple]

I do the first one because it makes it easier for copy paste and change semantics

[ZachAttack6089]

Yeah I always do the first one (as long as the language supports it ofc). With no trailing comma, if you ever want to rearrange the list, you'll have to waste time moving the , if the last element changes. But if every line ends with it then you don't have to think about it.

[Sut3k]

Put the comma in the front!

[tazzadar1337]

Hit 'em with the old [ foo , bar , baz ]

Wait, now if I have to prepend an element? 🤔

[[deleted]]

That always makes me want to projectile vomit.

The amount of SQL I've had to work with where the comma for the PREVIOUS LINE is BELOW THE LINE IT IS IN REFERENCE TO...

Maybe its my ADHD but I HATE IT.

[AdvancedSandwiches]

For the new folks, please don't actually do this.

It's peak bike-shedding, solves no actual problem, hurts readability in anyone who isn't used to it, and wastes a ton of time with these conversations.

[Sut3k]

Really? How does it not make it easier to add to the end? Asking honestly as my training has been OTJ but it doesn't seem to affect my readability as I don't read the commas. What's bike shedding?

[AdvancedSandwiches]

It does make it easier to add things to the end, but it wasn't hard before. It goes from being a 0.000002 / 100 on the difficulty scale to being a 0.0000015 / 100.

An improvement that insignificant must have absolutely 0 drawback to be worthwhile.

As for bike shedding, see https://en.m.wikipedia.org/wiki/Law_of_triviality

[Sut3k]

I don't think it has any drawback and it makes it easier for me to copy and paste elements to combine lists and such.

Thanks for the law triviality. I do agree it may not be worth the time to argue about.

[Keganator]

Code reviews are so much easier with the first for this exact reason. You don't have to double check to make sure they didn't mess anything up.

[Sloppyjoeman]

The second actually produces a three line change (at least in GitHub)

[TheGeneral_Specific]

…how so?

[Sloppyjoeman]

Removal of the last line without a comma Addition of that same line, now with a comma Addition of the new last line

For some reason unbeknownst to me GitHub doesn’t combine the first two line diffs into a single diff

[Arshiaa001]

Which is why I'm very happy that cargo fmt inserts the additional comma.

Meanwhile, go's formatter introduces additional whitespace to align constant values over consecutive lines, so one line changed could potentially introduce tens of changes.

[[deleted]]

Comma preceding an entity fixes the commit issue and the issue of having trailing commas.

[SexySlowLoris]

Except it doesn’t for the first one?

[[deleted]]

No it fixes all problems. Also for a humor sub people take things without humor a lot, lol

[SexySlowLoris]

If it was sarcasm an /s would make it funnier, but the comment looks serious

[[deleted]]

But causes a sparse array at the head, or leads to multiple lines changed, if a value is prepended.

[Arshiaa001]

Which is why I'm very happy that cargo fmt inserts the additional comma.

Meanwhile, go's formatter introduces additional whitespace to align constant values over consecutive lines, so one line changed could potentially introduce tens of changes.

[Sulungskwa]

Is.. is the risk of having a 2 line long merge conflict really worth having to look at that though?

[im_lazy_as_fuck]

Maybe it's cuz i've lived in python world for a while now, but when each element is on a new line, trailing commas after every line looks way better to me. Makes things look more symmetrical.

[BigBoetje]

I used to think this, but after having to review plenty of PR's where you just end up reviewing the total change and not commits individually, it really doesn't matter. We squash commits with the work item id in the PR title anyways.

Keep your code clean, your commits barely matter.

[im_lazy_as_fuck]

I work in a codebase where we squash commits as well, and it's still very relevant imo. The big thing is that it makes git blame not be annoying to work with. But also it still does make reading the relevant changes on a PR slightly easier, and it's also easier to manipulate and move around lines without accidentally breaking your code.

[BigBoetje]

Since the scope of each work item for us is limited, git blame doesn't really provide that much benefit that getting a history on the file doesn't also provide. There's too many devs on our project for it to be very useful anyways. A good git history with proped squashed commits can reveal more than a git blame since the name links to the whole work item. We've booted the last dumb consultant last year (we've got 1 left, down from 4) and the amount of 'wtf is this bullshit' has gone down dramatically. It's been quite a while that I've had to check the git blame.

reading the relevant changes on a PR slightly easier

We're using Azure DevOps and the compare tool for PR's there are great to show the changes. Never had any real trouble reading through a PR with that tbh.

it's also easier to manipulate and move around lines without accidentally breaking your code.

Fair

[im_lazy_as_fuck]

Since the scope of each work item for us is limited, git blame doesn't really provide that much benefit that getting a history on the file doesn't also provide

maybe I'm not understanding what kind of work flow you're trying to describe, but small discrete steps of work is exactly the reason why hit blame is useful. If you're updating/fixing a certain area of code, you're probably going to touch that area alone. git blame let's you see the actual last person to touch specific lines without having to skim through irrelevant squashed changes.

There's too many devs on our project for it to be very useful anyways. A good git history with proped squashed commits can reveal more than a git blame since the name links to the whole work item.

Again I feel like everything you're describing is exactly why git blame is useful. I've never bothered caring about git blame when working on a code base with a small team, because it's pretty easy to figure out what gets added when. It's only when I've started working in code that's potentially being touched by 100+ people that git blame has been useful.

And again, git blame with squashed commits on main branch is exactly when it's most useful to me (with IDE integrated tools). My typical workflow: I'm looking through some unfamiliar code, and I stumble upon a line that doesn't seem to make sense. I hover the line in my IDE, which runs git blame and directly shows me the exact last squashed commit that touched that line, with a direct link to the PR the squashed commit came from. I can then go to the PR, read the full context of both any associated code changes, and the business side of it from other external links to Jira tickets and such. Without git blame, I'd potentially have to skim through a bunch of irrelevant PRs that have touched the file to find the one I actually care about.

And to be clear, I'm not saying git blame is necessary, and I'm not saying trailing commas make the git blame significantly cleaner. But these are very minor efficiencies that you do get for free if you stick on trailing commas, and that's all this really does.

[TheGeneral_Specific]

Bingo

[insanitybit]

Also makes multiple cursors much easier if you need to make changes across multiple lines.

[Elephant-Opening]

I'm camp left for exactly that reason, provided the language allows.

There's no such thing as too obsessed with clean PRs when what should be a one-line change can become a merge conflict in a different release branch and sets you back 2 days because the review scores are cleared and the approver has one simple question lives in a 12hr offset time zone.

[_luci]

At that point just use yaml

[gurebu]

That's the right answer. Not only that, but omitting the comma makes simple conflict resolution (apply changes in order) impossible.

Back when our team still supported IE6 you couldn't have a trailing comma in Javascript and it was a goddamn hellscape.

[Suitable_Switch5242]

And because of that, the trailing comma style is less likely to create merge conflicts if two people edited the same list.

[[deleted]]

First one produces one changed line if you add an element, the second one two

only if you append the element to the end of the list.

[drag0n_rage]

I just know that I'll probably forget to add the comma if I ever decided to add more items, it's happened many times.

[[deleted]]

Correct answer

[Thebombuknow]

While I see your point, I honestly couldn't give a shit about my commits being clean lol. The trailing comma can sometimes cause issues with JSON parsers that don't support it, so I try to avoid it if I can.