I saw this topic getting some traction over on the Erlang Forums, so I want to resurrect this topic here (previous discussion here):
Should the Elixir formatter allow trailing commas?
- Yes
- No
0
voters
2 Likes
I copied this from my post on the Erlang Forums, since it’s one of my favorite side-effects of permitting trailing commas:
I’m not here to extol the virtues of Javascript, but they did get one thing very right by allowing optional trailing commas.
As mentioned by others, this allows for simplified diffs, but one major benefit IMO is that some of the auto-formatters (e.g. Prettier) allow the trailing comma to be used to define how a (short) list of items is formatted.
Given a short list of items:
a = [1, 2, 3]
If a trailing comma is placed at the end of a list, e.g.:
[1, 2, 3,]
Then the formatter will automatically split it into multiple lines when it is applied (e.g. on save, if auto-format-on-save is enabled):
[
1,
2,
3,
]
(This looks silly for a short list like this, but it demonstrates the point. It is nice to use for more complex data structures.)
Conversely, if the trailing comma is removed, then shorter lines will automatically be merged back to a single line. Longer lines will be split into multiple lines as needed (to maintain the configured max line length), and will have the trailing comma, as one would expect.
This feature is nested as well, so you have the ability to determine which structures can be placed on one line, and which should be split up into multiple lines:
[
%{hello: :world, goodbye: :troubles},
%{
hello: :world,
goodbye: :troubles,
},
]
It’s a small syntactic difference that can lead to much more readable code, IMO.
Elixir removes trailing commas by default (a mistake IMO, as it precludes the ability to apply the aforementioned formatter trick), but there is a custom formatter called Freedom Formatter which apparently implements this feature. (I have not used it myself since I prefer to stick to conventional code styles when possible, even if I prefer the customization.)
3 Likes
For some reason I always thought that the trailing comma was always removed as it was causing a compilation error 
.
I think in macros, that is true, but not for lists, maps, or other collections. So that would be one thing consider if that is the case.
EDIT: The code examples in my first post all execute successfully in IEx.
Indeed, a macro with a trailing comma will raise a compilation error. For example, this code:
defmodule HelloPhoenix.Repo do
use Ecto.Repo,
otp_app: :hello_phoenix,
adapter: Ecto.Adapters.Postgres,
# ...
end
produces this error:
Compiling 1 file (.ex)
== Compilation error in file lib/hello_phoenix/repo.ex ==
** (SyntaxError) invalid syntax found on lib/hello_phoenix/repo.ex:4:36:
error: unexpected expression after keyword list. Keyword lists must always come as the last argument. Therefore, this is not allowed:
function_call(1, some: :option, 2)
Instead, wrap the keyword in brackets:
function_call(1, [some: :option], 2)
Syntax error after: ','
│
4 │ adapter: Ecto.Adapters.Postgres,
│ ^
│
└─ lib/hello_phoenix/repo.ex:4:36
3 Likes
Rust’s formatter even forcibly adds a trailing comma at places (IIRC) and I love that. Simpler diffs indeed (not in long use blocks that get auto-wrapped by the same formatter however; those are unsalvageable).
So yeah I’m all for that, though I’m extremely skeptical that Elixir will have core language changes at this point. Even if it’s an optional thing that does look simple to us but likely carries a huge price to implement well.
3 Likes
This is because you do not have the square brackets. The parser does not know if some call is a macro.
+1 for trailing commas. They are already supported by the language, so no core change here. Just the behaviour of the formatter to change. Except for function calls but that’s far less useful IMO.
Having the formatter not removing them would already be a great change.
2 Likes
No because I need clarification. There are some good points about inline vs not in the linked thread. I don’t particularly like [1, 2, 3,] and especially not foo("bar",). Also, I’m pretty indifferent to them in general. I appreciate them very much for diffs but I enjoy not having them when reading. I’d almost prefer this be solved in git, kinda like how you can ignore whitespace in blames (and all the various other blame options).
3 Likes
There’s a difference between supporting trailing commas, and enforcing them.
Yeah, that would be ugly and unnecessary IMO (as a one-liner).
1 Like
Well solid “no” then since I like that it’s not configurable. I don’t even like that line length is configurable. I’d be fine with all or nothing but that would require enforcing syntax in the scenarios that is problematic for not currently supporting them. Though I wouldn’t cry about it if it became an option.
I also realize I didn’t fully read your second post before responding 
1 Like
I don’t think it would need to be configurable (unless I’m missing something)… it could just permit trailing commas at the end. Both [1, 2, 3] and [1, 2, 3,] would be untouched by the formatter. Presumably, this same could work for single-line and multi-line statements as well. It would be up to the user whether or not to use them.
I also prefer to stick to formatter defaults so I’m with you there.
Good point. When I add the square brackets, the trailing comma works (as long as I disable my editor’s format-on-save feature).
Right, I hadn’t thought about trailing commas there either, but I wouldn’t be in a rush to support that.
2 Likes
This is funny timing. I had this discussion with a couple of colleagues on Friday.
Personally I have no strong preference, but it seems that people that have been using Typescript or Rust are quite fond of those trailing commas.
I would prefer that the formatter neither adds or removes trailing commas, as to leave it up to the author.
But I also know that this may lead to quite a few “we need to agree on how to do this”-discussions, as there are different preferences.
Currently, the formatter makes a choice, which we can disagree with, but it is consistent. If it allows both, codebases will be more inconsistently formatted.
I guess the interesting thing is how many people to prefer the default to be changed from removing trailing commas to adding them. Make half developer happy, the other half unhappy? 
2 Likes
I wonder if a Credo check could be added for this…
I don’t see how these commas add readability 
It is just different, but not better.
In Elixir you already can add a new line symbol at the beginning of the list and it will do the same:
[
1, 2, 3]
On the other hand, diff won’t be that much simpler. IMO, that’s the problem of diff tools, not the language per se. I highly recommend GitHub - Wilfred/difftastic: a structural diff that understands syntax 🟥🟩 if readability is a concern, it also handles more complex cases.
Tried it once, the output was very confusing but it might have been the color scheme. Can you customize it? Or, rather, do you use difftastic and how?
I think diffs are one part of the story, but another argument is that it removes friction when re-ordering items by moving lines around as well.
Not a major issue at all, but small pain that could totally be avoided with trailing commas.
The main concern I have with trailing commas is that they are not supported in function arguments, so this might introduce some visual inconsistency perhaps. But since lists / maps have distinct ASTs, I don’t think it’s an issue in practice.
11 Likes
GIT_EXTERNAL_DIFF=difft git diff
Or do:
git config --global difftool.difftastic.cmd 'difft "$LOCAL" "$REMOTE"'
git config --globa diff.tool difftastic
And then you can just use git difftool when you want Difftastic.
1 Like
Well duh, not what I asked but thanks.
The removal of trailing commas in list and map (not calls) is causing trouble a bit especially when you deal with options passed to some macro generator. Think that you want to check something part by part i.e.:
[
key1: :value1,
key2: :value2,
key3: :value3,
# key4: :value4,
# key5: :value5,
]
When you have configured your editor to format file on save then the comma would be removed after :value3. The problem is when you want to uncomment next option(s). Every time I’m doing that I need to add the comma back which is of course simple, but really unnecessary.
Removing a single character does not help at all in my opinion and in some cases it distracts people which is really bad having in mind that Elixir was built with an approach of focus on a work on the actual problem.
11 Likes
Yeah that’s my usual problem – moving stuff in a list. The auto-removal of the comma from the last element always throws a wrench in what should be a near-brainless process.
7 Likes
