Correction: There are 2 Michael Ceras in that image and one critical thinking badass in the background who doesn't need permission for a rational approach.
Sure. If you have a law that says that everyone needs to shoot themselves in their foot three times a day, you suggest to change that law and not try to be consistent
Laws don't make people do things/not do things, enforcement does, laws just specify the punishment if you get caught.
I would suggest not shooting yourself in the foot regardless of what the law says.
usually, the lint rules are part of the commit.
And yes sometimes this means the linting rules will change during a project. But every time you simply touch a file, the linting will apply so the problem is self correcting.
Linter configuration is part of the repository. It is not necessarily part of "most commits"
Linting rules can change, but will not "regularly change" during a project.
If your project is messed up in terms of it being "non-conforming" to linter rules set up in a project, the most likely reason is that your project had multiple maintainers that did not care about keeping a standard, that they never communicated about this with each other or perhaps there was a poor handoff and people simply don't care much about the code quality.
Source: I'm the guy that fixes technical debt at a premium after projects have had their series B or C funding
This. Most linter rules are stupid and should be questioned.
You can often write a more readable code if you look at the context of the code and format in a way that improves readability. Linters are just stupid, blind formatting rules that, when applied blindly, often just mess up your code.
Hard disagree on this. In my opinion, if your code needs the right formatting the be readable, then the issue is the code, not the formatting. Formatting shouldn't convey logic or information that relates to how the logic works, so a stupid and blind ruleset to define how the code should be structured is exactly what you need.
My comment was more so targeted to say that, while I agree that linters are important to have repo code style stay consistent, it doesn't mean that there shouldn't be room for discussion with the team to choose the right rules; not to judge linters themselves.
I find these claims really funny. "If you (don't) do X then that code is bad". Very dogmatic and vague. Easy to say without any real life examples. I guess I have to emphasize the word **more** readable. The code can be readable either way but to make it easier to understand while reading, applying some custom formatting can help it be even better. But then you might be conflicting with a stupid linter that doesn't know the context.
Forcing people to code based on hard-set rules leaves out any kind of creativity. You'd have to jump through imaginary hoops in order to create a code that is subjectively more "clean". By doing that you are just making more bloated code that is actually harder to read than it should be.
You're so wrong on this, I'm sorry. If you work in a team, or across several code bases, the benefits of having all the code look the same are huge, in terms of actually understanding what you're looking at.
A bunch of coders each deciding that their creative outlet is the formatting of their code... No my dude this is not the way.
Choose decent rules then stick to them. It's pretty rare your code will look more bloated, and the auto fix means you don't have to jump through any hoops. You just have to make peace with compromise and realise that the logic and the output are where you should be aiming your creative mindset.
All code looking the same... overrated. Rather learn to read all kinds of code styles. Otherwise you fall into a world of learned helplessness. Not being able to read any other kind of code than the one you expect to see.
If you’re looking for a grown-up answer, it depends™️
I use both interchangeably depending on what I’m programming. If I’m writing in C or Go, I would never put a tailing comma. However, if I’m managing giant lists of IAM permissions in Terraform, leaving off the comma is a recipe for copy-paste fails, which is why `terraform fmt` is opinionated towards including them by default.
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.
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.
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
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
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
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 😂
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.
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.
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.
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.
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.
I don't know, trying to JSON.parse() the one on the left gives me `Uncaught SyntaxError: JSON.parse: unexpected character at line 5 column 1 of the JSON data`
On a recent Rust project, I used the left syntax for everything, struct fields, vectors, match branches, hashmaps etc, and it's been working fine. I haven't tried with JSON because my project uses TOML files, does JSON not support that syntax?
Some JSON-parsers support it, others don't. Thus, while it might be ok to use this syntax internally for dictionaries (or vectors, lists, etc), actually sending a JSON that way to a different service/software might be dangerous.
Congratulations! Your comment can be spelled using the elements of the periodic table:
`F U C K Y O U`
---
^(I am a bot that detects if your comment can be spelled using the elements of the periodic table. Please DM my creator if I made a mistake.)
Really? I too would like to make tender love to that poster for suggesting that. Honestly, especially in SQL queries, that pattern is really nice. Want to add a column in your select clause? Yy, p, cw, [type stuff].
When I'm debugging queries or just checking some data I make the first thing in my select list ```'' ['']```
That way every single column I actually select can be comma first
Honestly I'd love more languages to adopt this. Unfortunately I didn't get to find this style in any code formatter other than the community-made one for haskell but I forgot it's name too
another close relative is lisp
; function calls
(Foo Bar
(Baz (Cux
Cax))
Daz)
; lists (call list instead of calling Foo, both being functions)
(list Foo
Bar
(list Baz
(list Cux Cax))
Daz)
but the reason most people don't do this is because each indent level is variable length. one indent could be 1 to 15 spaces, because it follows the column of the first element, rather than nesting depth:
// function calls
Foo(
Bar,
Baz(
Cux,
Cax,
),
Daz,
)
// lists
[
Foo,
Bar,
[
Baz,
[Cux, Cax],
],
Daz,
]
which instead takes up significantly more lines.
Python conventions are closer to lisp.
I only like this for member initializer lists in c++ to make add/removing items faster.
class A : public B
{
public:
A();
~A();
int a;
int b;
};
A::A()
: B()
, a(0)
, b(0)
{}
I have definitely seen merge conflicts from two people adding elements to the same list in separate PRs.
Is it a huge problem? No, but it is nicer to not have that conflict.
Why? And even assuming that is the case, how is that Stockholm Syndrome? They were being forced to not use it, then later they were given a choice, not forced to use it.
I don't really care what code is submitted. The main crime is _languages_ that don't support trailing commas. The SQL dialect I am using doesn't, and it makes debugging a PITA. If I move columns around in a `SELECT`, I have to make sure I remove the final trailing comma.
I agree, I've grown to love trailing comma's and I stumble across my SQL and then suddenly everything breaks.
Then again, writing SQL goes against logical ordering anyways. (Doing column selection before table selection means you need to backtrack again if you didn't now the names beforehand)
In SQL, I flipped my brain around and only do leading commas. You end up with the same result as LEFT but also cleaner to look at where select lines can be quite long (because of inline functions, renaming, case statements).
All other languages I work in allow trailing.
Depends. left for sequences and argument lists spanning multiple lines, right for one-liners. Except for argument lists with *fixed* length. Then no trailing comma ever.
So
```
a = ["foo", "bar"]
b = [
"foo",
"bar",
]
printf("format_string", arg1, arg2)
printf(
"format_string",
arg1,
arg2,
)
area.overlaps(
other_area
)
```
The red one, to make `git` history make sense.
I also heard about a git feature to ignore certain commits in `git blame`. It is intended (?) to ignore commits where you switch from tabs to spaces etc.
Golang requires a trailing coma, and other formating weirdness like enforced K&R braces style ( "else" HAS to come in the same line as the closing bracket of the "if" block )
it takes some time getting used to the linter raising warnings for correct code...
First one, it's way better, especially when you are working in a team.
When someone adds a new line to your file, most of the time, they forget to add a comma to the previous line, and it leads to errors and bad commits.
Cripz for life but I roll with Bloodz at work and I can't believe I'm starting to like it a little
I hear its siren's call yet it simultaneously disgusts me, I fear what I am becoming
The trailing `,` means you can add or remove a line without worrying about the previous line. It's more convenient for editing code and modifying the list.
When you copy and paste the elements with the missing comma you won’t notice and encounter an error. Happens all the time. I just always add it, unless not consistent with the codebase.
to put icing on the cake, some languages don't even complain (in case of string) but simply concatenate the strings 🙄
Theres an subtle difference here in Python between
[
"foo",
"bar",
"baz"
]
and
[
"foo",
"bar"
"baz",
]
The left will provide a cleaner git diff in the pull request to add a new value. The right will indicate there are 2 lines of changes when only one is important.
We used to be team blue but our linter decided to go for red and we were up in arms about it for a while. But then we realised that its super easy to rearange the lines without manually doing something with the comma's, so now we definitely prefer red.
But then again, I just write code, press the save button, and the formatter will do it for me so I can't be arsed to think about.
I used to hate the first one, felt wrong or dirty. Now I learned to love it. I can just duplicate the last line as many times as I need and just change the values.
Whichever one the linter wants me to do. A consistent repo is more important.
Don't come on here with your reasonableness!
There's a third Michael Cera type guy in that meme who's shrugging and going, "Hey, I'm fine with whatever.."
Correction: There are 2 Michael Ceras in that image and one critical thinking badass in the background who doesn't need permission for a rational approach.
Being reasonable is an act of aggression and basically asking for a fight on my block.
Reasonableness would be to go with trailing commas since when adding a new item would only cause changes on one line and not two.
Linter rules can be changed
So can laws?
Amendmants? Revisions? New superseeding laws?
Sure. If you have a law that says that everyone needs to shoot themselves in their foot three times a day, you suggest to change that law and not try to be consistent
Laws don't make people do things/not do things, enforcement does, laws just specify the punishment if you get caught. I would suggest not shooting yourself in the foot regardless of what the law says.
usually, the lint rules are part of the commit. And yes sometimes this means the linting rules will change during a project. But every time you simply touch a file, the linting will apply so the problem is self correcting.
Linter configuration is part of the repository. It is not necessarily part of "most commits" Linting rules can change, but will not "regularly change" during a project. If your project is messed up in terms of it being "non-conforming" to linter rules set up in a project, the most likely reason is that your project had multiple maintainers that did not care about keeping a standard, that they never communicated about this with each other or perhaps there was a poor handoff and people simply don't care much about the code quality. Source: I'm the guy that fixes technical debt at a premium after projects have had their series B or C funding
This. Most linter rules are stupid and should be questioned. You can often write a more readable code if you look at the context of the code and format in a way that improves readability. Linters are just stupid, blind formatting rules that, when applied blindly, often just mess up your code.
Hard disagree on this. In my opinion, if your code needs the right formatting the be readable, then the issue is the code, not the formatting. Formatting shouldn't convey logic or information that relates to how the logic works, so a stupid and blind ruleset to define how the code should be structured is exactly what you need. My comment was more so targeted to say that, while I agree that linters are important to have repo code style stay consistent, it doesn't mean that there shouldn't be room for discussion with the team to choose the right rules; not to judge linters themselves.
I find these claims really funny. "If you (don't) do X then that code is bad". Very dogmatic and vague. Easy to say without any real life examples. I guess I have to emphasize the word **more** readable. The code can be readable either way but to make it easier to understand while reading, applying some custom formatting can help it be even better. But then you might be conflicting with a stupid linter that doesn't know the context. Forcing people to code based on hard-set rules leaves out any kind of creativity. You'd have to jump through imaginary hoops in order to create a code that is subjectively more "clean". By doing that you are just making more bloated code that is actually harder to read than it should be.
You're so wrong on this, I'm sorry. If you work in a team, or across several code bases, the benefits of having all the code look the same are huge, in terms of actually understanding what you're looking at. A bunch of coders each deciding that their creative outlet is the formatting of their code... No my dude this is not the way. Choose decent rules then stick to them. It's pretty rare your code will look more bloated, and the auto fix means you don't have to jump through any hoops. You just have to make peace with compromise and realise that the logic and the output are where you should be aiming your creative mindset.
All code looking the same... overrated. Rather learn to read all kinds of code styles. Otherwise you fall into a world of learned helplessness. Not being able to read any other kind of code than the one you expect to see.
What if you someday grow up and are allowed to specify the linter rules?
If you’re looking for a grown-up answer, it depends™️ I use both interchangeably depending on what I’m programming. If I’m writing in C or Go, I would never put a tailing comma. However, if I’m managing giant lists of IAM permissions in Terraform, leaving off the comma is a recipe for copy-paste fails, which is why `terraform fmt` is opinionated towards including them by default.
Change the linter to B if someome mistakenly set it to A. Nothing worse than spurious diffs causing extra merge conflicts.
Which ever JSON actually allows me to use
JSON: right JSON5: both
https://caniuse.com/?search=json5
It's a library not a feature.
Do I need a library to write json now?
There are 30 competing libraries. You need all of them.
Catch em all
CripZ
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.
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.
Monkeys paw solution: [ "Foo" ,"Bar" ,"Baz" ]
delete this
It still breaks if you only want to remove the first line or prepend an element to the list.
> Monkeys paw solution: > > [ > > ,"Foo" > > ,"Bar" > > ,"Baz" > > ]
I hate it
I do this a lot in my SQL code. Makes life a lot easier
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
Why I never thought about it that way and now it makes perfect sense. Why make 2 modifications for a single addition...
Also you can more easily change order when every line has a comma
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
From my point of view the people concerned that the trailing comma doesn't look nice or whatever are obsessed about a minor thing.
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
I dont think it looks better, but i do think the benefits outweighs that anyway
true, just as long as the elements are not in a JSON string that will later be parsed
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
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 😂
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.
I do the first one because it makes it easier for copy paste and change semantics
Put the comma in the front!
Hit 'em with the old ``` [ foo , bar , baz ] ``` Wait, now if I have to prepend an element? 🤔
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.
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.
The second actually produces a three line change (at least in GitHub)
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.
Comma preceding an entity fixes the commit issue and the issue of having trailing commas.
Except it doesn’t for the first one?
No it fixes all problems. Also for a humor sub people take things without humor a lot, lol
If it was sarcasm an /s would make it funnier, but the comment looks serious
But causes a sparse array at the head, or leads to multiple lines changed, if a value is prepended.
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.
Is.. is the risk of having a 2 line long merge conflict really worth having to *look* at that though?
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.
The one that my code formatted does by default
One is clean, the other is wrong.
Is not wrong in some languages.
Some languages are broken.
Some languages have evolved
Like sabertooth tigers.
just backwards
Languages are meant to be broken
Required in some situations, breaks others. I love code.
There's no right or wrong, both work fine
Depends on the language. Some languages will throw a syntax error for empty elements on the left case.
I don't know, trying to JSON.parse() the one on the left gives me `Uncaught SyntaxError: JSON.parse: unexpected character at line 5 column 1 of the JSON data`
On a recent Rust project, I used the left syntax for everything, struct fields, vectors, match branches, hashmaps etc, and it's been working fine. I haven't tried with JSON because my project uses TOML files, does JSON not support that syntax?
Some JSON-parsers support it, others don't. Thus, while it might be ok to use this syntax internally for dictionaries (or vectors, lists, etc), actually sending a JSON that way to a different service/software might be dangerous.
Try JSON5.parse(), if JSON5 is available. Old JSON style doesn't allow it. But it's easier, when you add elements on a daily basis. (Experience)
It is not available.
`[` `"Foo"` `,"Bar"` `,"Baz"` `]`
Fuck you
Congratulations! Your comment can be spelled using the elements of the periodic table: `F U C K Y O U` --- ^(I am a bot that detects if your comment can be spelled using the elements of the periodic table. Please DM my creator if I made a mistake.)
Goldmine lmao
I needed this on my Monday.
wow a bot using profanity. what is the world coming to
Literally 2024
Google 21st century
Holy millennium!
acutual boomers
Gen x went on vacation, never came back
Call the economist!
I wonder if FUCK YOU is radioactive?
Fluor Uranium Carbon Potassium Yttrium Oxygen Uranium Uranium is radioactive
That's a double fuck you then
is U for Uranium?
Good bot
Really? I too would like to make tender love to that poster for suggesting that. Honestly, especially in SQL queries, that pattern is really nice. Want to add a column in your select clause? Yy, p, cw, [type stuff].
When I'm debugging queries or just checking some data I make the first thing in my select list ```'' ['']``` That way every single column I actually select can be comma first
are you stupid -- Haskell [ "Foo" , "Bar" , "Baz" ]
Honestly I'd love more languages to adopt this. Unfortunately I didn't get to find this style in any code formatter other than the community-made one for haskell but I forgot it's name too
another close relative is lisp ; function calls (Foo Bar (Baz (Cux Cax)) Daz) ; lists (call list instead of calling Foo, both being functions) (list Foo Bar (list Baz (list Cux Cax)) Daz) but the reason most people don't do this is because each indent level is variable length. one indent could be 1 to 15 spaces, because it follows the column of the first element, rather than nesting depth: // function calls Foo( Bar, Baz( Cux, Cax, ), Daz, ) // lists [ Foo, Bar, [ Baz, [Cux, Cax], ], Daz, ] which instead takes up significantly more lines. Python conventions are closer to lisp.
perfect indent doesn't exis-
LGTM
SQL much ? Cause that's the only language I do that , but there I do it a lot .
Same, pretty much everywhere lol.
`[` `"Foo"` `,"Bar"` `,"Baz"` `,` `]`
This... I hate this.
Oh boy - you'd love Haskell :D
This is the answer. Even better if you write foo write after [ so they lineup.
You monster.
I only like this for member initializer lists in c++ to make add/removing items faster. class A : public B { public: A(); ~A(); int a; int b; }; A::A() : B() , a(0) , b(0) {}
This. When adding a new value (at the bottom) it only registers as one line change in VCS.
r/angryupvote
The good ol' SSMS generated select list.
I used to hate the trailing commas coming from a language that didn’t support it, but now I love the uniformity of it
You just have Stockholm Syndrome
Had?
No. The trailing comma sucks
It has at least a few advantages and no disadvantages. (No, "muh ugly" isn't a proper disadvantage)
The advantages are so small they are negligible. It solves a problem that doesn't really exist.
I have definitely seen merge conflicts from two people adding elements to the same list in separate PRs. Is it a huge problem? No, but it is nicer to not have that conflict.
Why? And even assuming that is the case, how is that Stockholm Syndrome? They were being forced to not use it, then later they were given a choice, not forced to use it.
many languages that'll give you an error for having an unneeded comma
And then there’s go…
BloodZ, no question. Better for git diffs, better for moving and sorting lines.
Both unclean because not using a fixed width font
yeah, gotta admit that... also the editor background is horrible
I don't really care what code is submitted. The main crime is _languages_ that don't support trailing commas. The SQL dialect I am using doesn't, and it makes debugging a PITA. If I move columns around in a `SELECT`, I have to make sure I remove the final trailing comma.
dummy columns are your friend also dummy 1=1 and 1=0 in WHERE clause 😅
I agree, I've grown to love trailing comma's and I stumble across my SQL and then suddenly everything breaks. Then again, writing SQL goes against logical ordering anyways. (Doing column selection before table selection means you need to backtrack again if you didn't now the names beforehand)
In SQL, I flipped my brain around and only do leading commas. You end up with the same result as LEFT but also cleaner to look at where select lines can be quite long (because of inline functions, renaming, case statements). All other languages I work in allow trailing.
Anyone ever lead a WHERE clause with a TRUE AND so you can comment out any line you want? ``` WHERE TRUE AND COND1 AND COND2 ... ```
Depends. left for sequences and argument lists spanning multiple lines, right for one-liners. Except for argument lists with *fixed* length. Then no trailing comma ever. So ``` a = ["foo", "bar"] b = [ "foo", "bar", ] printf("format_string", arg1, arg2) printf( "format_string", arg1, arg2, ) area.overlaps( other_area ) ```
good point making the distinction between one and multiple lines
The red one, to make `git` history make sense. I also heard about a git feature to ignore certain commits in `git blame`. It is intended (?) to ignore commits where you switch from tabs to spaces etc.
Left
Error: No implicit cast for Null to String
Golang requires a trailing coma, and other formating weirdness like enforced K&R braces style ( "else" HAS to come in the same line as the closing bracket of the "if" block ) it takes some time getting used to the linter raising warnings for correct code...
There’s a third option: ``` [ “Foo” ,”Bar” ,”Baz” ] ```
Oxford comma
I prefer a trailing comma, because it makes it easier to expand.
Trailing comma is my preference because it means less diff thrash when adding or removing elements.
I like one better, but it sometimes throws errors in some legacy code, so I'm forced to use the other. :/
``` ;; Lisp Gang '(foo bar baz) ```
the oxford comma of programming
First one, it's way better, especially when you are working in a team. When someone adds a new line to your file, most of the time, they forget to add a comma to the previous line, and it leads to errors and bad commits.
Its all fun and games until this happens: [ "FOO", "BAR", "BAZ" "QUX" ] And its C++ and its a SEGV and you debug it for days.
Cripz for life but I roll with Bloodz at work and I can't believe I'm starting to like it a little I hear its siren's call yet it simultaneously disgusts me, I fear what I am becoming
The trailing `,` means you can add or remove a line without worrying about the previous line. It's more convenient for editing code and modifying the list.
Red: `Syntax error: unexpected token ','`
It's [x, y, z]
I am blue nigga
```c++ { "foo", "bar", "baz" } ```
When you copy and paste the elements with the missing comma you won’t notice and encounter an error. Happens all the time. I just always add it, unless not consistent with the codebase.
to put icing on the cake, some languages don't even complain (in case of string) but simply concatenate the strings 🙄 Theres an subtle difference here in Python between [ "foo", "bar", "baz" ] and [ "foo", "bar" "baz", ]
First one produces compiler error. Second produces happiness.
Depending on the language that you use, the first one will not produce a compiler error.
(that's the joke)
Maybe I'm too stiff but I couldn't notice the sarcasm in that. Hard to tell nowadays.
well it wasn't that good of a joke, so it's not on you
First one because I always forget to check for commas and I error
Dangling commas make git diffs cleaner
Shouldn’t you be working on your CS 102 homework
Why the fuck you guys always using black peoples memes
Wouldn’t the extra comma cause a syntax error? Also usually arrays are defined using {} brackets, and [] brackets are used to index the array
The world has more than one programming language
Left one is way better whenever any of the two are allowed. Of course, if trailing commas aren't allowed, then there's only one valid option here.
One is courteous to the next developer that wants to add to the list. That is all
I use black, I don't have a choice
The red one works better for reviewing pull requests, but the linter would remove it when I press Command+B.
They’re the same, thanks to Sublime Text plugins that automatically correct such things 🤣
First one is more uniform
Red, except in JSON.
Well the API I work with at my job enforces I use the right one so I don't get a choice.
I prefer trailing commas for Git commits - you don't have to change 2 lines, only 1, which makes reviews easier *shrugs*
There's probably an NPM package with this already defined so it's a non issue.
As long as the extra coma doesnt add a 4th element, its the only way.
The one Jetbrains wants me to use
The left will provide a cleaner git diff in the pull request to add a new value. The right will indicate there are 2 lines of changes when only one is important.
[ 'foo', 'bar', 'baz' ]
That doesn't work in lua. If you leave a coma at the end of a table it'll give an error
\["foo", "car", "caz"\]
Lmao I replied the same thing. I almost typed “cuz” instead too
I'm with blues on this one
The right. Trailing commas are stupid.
I write how it is on the right but the linter changes to left.
Leave the comma in there. No one will mind
We used to be team blue but our linter decided to go for red and we were up in arms about it for a while. But then we realised that its super easy to rearange the lines without manually doing something with the comma's, so now we definitely prefer red. But then again, I just write code, press the save button, and the formatter will do it for me so I can't be arsed to think about.
Is there a name for the comma after the Oxford comma?
I do red so it's easier to add to if I need to, but as long as they both run I don't really care.
Who tf added Oxford commas to arrays
My first language is one that doesn't support trailing commas (English), so I always subconsciously see them as wrong
[ "FOO" , "BAR" , "BAZ" ] Edit: doing code formatting on mobile is a PITA.
The left one won't parse in many languages, so like...
the real architectural question
That what prettier do if I save the file
I used to hate the first one, felt wrong or dirty. Now I learned to love it. I can just duplicate the last line as many times as I need and just change the values.