To be honest, I wonder when git is smart enough to realize that when working with certain source code files, a line change that only adds a comma to the end is not that important. 
Qqwy
TypeCheck Core Team
1
OvermindDL1
You are separating a sentence, basically a single ‘expression’, what this is talking about is when expressions-as-arguments are long enough that they no longer fit on one line, other-wise yes you would only use a single line. 
It’s all exampled in this thread.
Yep yep, we need a Bikeshedding category/tag on these forums. ^.^
Then it’s not a perfect textual diff. ^.^
1
ryanwinchester
it’s arguably better if that single line of text has a lot of horizontal scrolling.
it’s the same idea with lists, and maps, etc.
sometimes you write them in a single line, and other times, you don;t
2
Deithrian
In my personal and inexperienced opinion, a function with 30 arguments is Ebola.
Please don’t encourage/facilitate people to write such functions.
2
OvermindDL1
Indeed long argument functions are painful, however a singular argument can be long in a set as well as it may not be a function but rather a macro thus the shape of the resultant AST needs to be kept intact.
1
Deithrian
ryanwinchester
It might not be that you have a lot of arguments, but that the arguments themselves are long. for example with pattern matching
def some_user_company_thing(%User{} = user, %Company{} = company, params \\ %{}) do
#
end
even just that starts getting long, imagine adding a guard
def some_user_company_thing(
%User{} = user,
%Company{} = company,
params \\ %{},
) when something do
# ¯\_(ツ)_/¯
end
maybe i’m weird but i prefer to see things like that than start horizontal scrolling in my code.
also, i don’t care a whole lot about the trailing comma, it’s helpful but not a huge pain point, it was mostly a tongue-in-cheek post, but we managed to get some discussion out of it 
3
Deithrian
Idk.
In my world, function arguments indicate only what the function accepts.
I would never manipulate data there, because that’s supposed to happen in the function body.
I feel that if manipulation happens in the function arguments, as well as in the function body, there’s now two places where bugs can happen.
Combined with SRP, my arguments never get long. ¯\ (ツ) /¯
def function_name(data1, data2 ,data3) do
“do stuff with data1,2,3”
end
1
OvermindDL1
Huh, this same issue got discussed on the ReasonML repo lately too, they gave a good reason (this is the owner of ReasonML speaking):
https://github.com/facebook/reason/pull/1775#issuecomment-359957416
I’ve found that trailing commas help with a bit of paren-fatigue as well, because it helps you distinguish closing parens for arguments/tuples/variants from parens whose only purpose is to resolve precedence - at least in the case where things break onto multiple lines. It’s a small help, but it is a help.
2
augnustin
I think people who aren’t supportive with trailing comma are the ones who never used it.
Eg. @WolfDan:
Hum it seems useless hahahaha
You completely discredited yourself by not being aware of what the topic was about. 
IMHO:
In addition to the git diff argument, a few haven’t been mentioned:
- so many mistakes would be avoided: when you duplicate a line, or invert two lines, and don’t see that one of those doesn’t have the comma, it is another 5 seconds lost
- in general, when writing enumeration in code, it is much more comfortable not to have to think is this the last item of my list? and put a comma instinctively
I understand that this is not compatible with optional parenthesis, which, even though I am not a big fan of it, makes functional code clearer (since functional means that there will be many function calls, hence many parentheses).
But I think it is worth the price.
Removing optional parenthesis would encourage us to write less nested code, which is a positive external effect of it.
Cheers
2