Code formatter incorrectly formats multiline lists when there is a trailing comma

[pragdave]

The docstring says

As mentioned in the previous section, lists, tuples, bitstrings, maps, and
structs will be broken into multiple lines if they are followed by a newline in
the opening bracket and preceded by a new line in the closing bracket lines.

However, this code:

  @deps [
    { :private, "> 0.0.0" },
    { :ex_doc,  "~> 0.14", only: :dev, runtime: false },
  ]

gets formatted as:

  @deps [{:private, "> 0.0.0"}, {:ex_doc, "~> 0.14", only: :dev, runtime: false}]

Cheers

Dave

[fishcakez]

This looks like an issue with multiline lists combined with a trailing comma. The formatter will remove the trailing commas but then not honor the multiline list. Rather it should remove trailing comma and honor the multiline list.

[pragdave]

Fwiw, multi line lists are exactly where a trailing comma is good...

[fishcakez]

Fwiw, multi line lists are exactly where a trailing comma is good...

Please try to stay objective :). A topic like trailing commas can invite lots of opinions and not many facts. Elixir current style does not use trailing commas and the formatter follows the existing style. If you can show that it would be of benefit please propose it separately.

[pragdave]

Objectively: 1. A trailing comma never hurts. 2. A trailing comma makes it easier to add 3. A trailing comma means you can sort a kv literal on key.

[fishcakez]

Right, it makes refactoring easier, and works nicely for history as this creates the minimal diff because a change has the smallest area of effect. I am unsure if it has a slight negative effect clarity of code for those who are not used to it. Perhaps that becomes moot, except for beginners, if the formatting is widespread. I think a similar example is piping into a case where it is not obvious until you have seen it a few times, and then it is obvious.

[pragdave]

So will the formatter not strip trailing commas going forward? Again, this is the compromise solution. If people don't use them, the formatter is happy. If people do use them, it's also happy.

[fishcakez]

I think this (and #6647) bring up a point about where the line is drawn between consistent style and flexibility. The current method is quite rigid and mandates the style, which can improve productivity as there is no discussion or leg work to be had on each project or change. On other hand being more flexible allows people to express they code how they feel is clearest and make more trade offs for themselves. Personally I don't know where this line should be.

[pragdave]

Well, if you decide the formatter should strip trailing commas because that's the Elixir way, perhaps the parser should be changed no longer to support them.

[josevalim]

Thanks for the report @pragdave! It has been fixed on 9b5af33.

Our goal with the formatter is to mandate a style, reducing the amount of discussion on each project or change and also ensuring everyone in the community follows the same guidelines.

We will likely end-up adding more flexibility but it is still too early to tell which ones. Everyone is going to have preferences on which formatting rules they would like to keep and if we adopt all of them then the formatter loses its goal of unifying the styles across the community.

[pragdave]

Our goal with the formatter is to mandate a style, reducing the amount of discussion on each project or change and also ensuring everyone in the community follows the same guidelines. I wonder if a linter would meet these goals better than a formatter?