Something that this thread makes me believe—though I’m sure others will likely disagree—is that the formatter is too aggressive. I may prefer a formatter that has a little more respect for the author’s whitespace choices. Consistent code is a worthy goal, but perhaps it would be easier to infer some decisions from the author, rather than attempt to maximize the utility of a single style (or require additional configuration in the case of locals_without_parens).
+10 on trailing commas.
Hear hear. I love most of what the formatter does. Just in a few cases I really really do not want it to touch some things. ^.^;
I would store it as a module attribute and then access it in the function body.
You are right. That’s the argument for trailing commas but no parens calls in Elixir make trailing commas a bit inconsistent. For example, you can’t do:
defstruct foo: :bar,
baz: :bat,
So we felt adding trailing commas could actually cause misunderstandings due to this “inconsistency”.
The issue is that it is most likely that you are inconsistent in those choices and do not always follow them in your codebase. We could add options for controlling things like using trailing commas or not, but then people will be bikeshedding on which options to enable. We have three options and they all have cons:
One of the things I am really enjoying about the formatter is that I now type code without any care about style and let the formatter do the job. It is absolutely liberating. Respecting the user’s choice means being more careful.
That’s why I want to wait the formatter to really be on the wild before adding more configuration or respecting more the user’s decision.
To me it is definitely a “choose your poison” kind of deal and we have chosen ours. Maybe marking parts of your code the formatter should not touch is a fair compromise but again, it is too early for that.
For the record:
iex(5)> Code.format_string!("#! foo")
["# ! foo"]
iex(6)> Code.format_string!("#!foo")
["# !foo"]
This begs the question. Is the goal of the formatter to reach total consistency, or is the goal to improve readability? In my opinion, too much consistency might actually have negative effects on readability, so just striving for consistency might IMO be counterproductive.
I personally confess that I’m sometimes inconsistent, and in many cases this is deliberate. A simple example are tuples. If they are very short, I write them on a single line, otherwise I put each element on a separate line. Same thing goes for maps.
Empty lines are another example. I sometimes use them to break and separate larger subsections in the code. OTOH if the code is very simple, I don’t bother.
That’s why I want to wait the formatter to really be on the wild before adding more configuration or respecting more the user’s decision.
It seems that the initial formatter is going to be quite opinionated, and given what I stated above I’m not enthusiastic about it. Personally, I’d prefer a more relaxed formatter initially.
Another way to put it is that with the formatter we stop paying attention to how layout affects readability, and instead completely delegate this task to the machine. I’m not saying this is bad, but I’m also not sure I like the fact that this is now in complete control of the machine. Personally I’d prefer a more balanced approach, where the machine takes care of mostly mechanical tasks, while people are responsible for case-by-case decisions. Unfortunately, I have no idea what exactly does this means, and whether it’s even possible.
Those decisions are also taken by the formatter based on the line length. The formatter won’t split a data structure into multiple lines unless the data structure was previously broken into multiple lines (so this is one of the cases where we respect the user’s choice - those few cases are all documented).
We need to remember that the issue is not only consistency with ourselves but also within our teams. This became clear to me as the Elixir team grew because they would ask me why I chose a certain layout and I could not give a reasonable answer. There was no pattern besides “it feels better”.
Empty lines were particularly an issue with Phoenix, where Chris would remove my empty lines and add them elsewhere and I would remove his empty lines and add them elsewhere. We would just do it subconsciously (to be fair, I probably did it more frequently than him 
).
It is still worth reminding that you cannot run the formatter blindly on an existing code base. Sometimes you will need to change the code to get a better output. Once you work on those and familiarize yourself with the formatter style, the cases where everyone agrees the formatter code is arguably worse are rare. For those still on the fence, the Elixir codebase is a good place to get started, since it has been fully formatted.
We generally follow the opposite approach when designing code and APIs in Elixir. We always start with the most restricted APIs and behaviours and then add options and flexibility later on. The reason is that it is relatively easy to add something later but it is extremely hard to remove something.
Btw, another idea I had yesterday is to define it as a list of lists. It may actually reflect better the origin of the data since you have a comment there that says “each row defines a dimension”. Then you flatten it and convert it to a tuple.