It’s a code smell because typically when you overload a function head, it masks the critical part of what you’re matching on. Code is about communication; names, whitespace, and line lengths matter.
Of course, this is all subjective—I admit to having strong preferences—and sometimes it is necessary to format across multiple lines; hence that 1 out of 10 loophole.
Code is about communication; names, whitespace, and line lengths matter.
No argument here, but I wouldn’t go as far as saying it “masks” anything critical because is totally your perception about it, and I respect that. My point is that because it’s subjective, I don’t think we can quite classify it as a code smell so objectively as you did 
.
To me one of the big benefits of the formatter is that it has so few options. A good chunk of elixir dependencies uses the formatter, so there’s no difference between looking at code I wrote or some third party code. Yes, to get to “one way of formatting” one has to make subjective decisions once, but when they’re taken there’s no need to discuss them further. There are some cases where the formatter doesn’t produce optimal code, but many times I’ve found ways to make it work. Given those are the 1% I’m happy to make those changes to get the benefits for the other 99%.
@LostKobrakai You know that 80% of statistics are false right!? haha 
When talking about code I don’t like compulsory standards - that’s one of the reasons I would not touch python and other languages with similar mantras like: “There should be one - and preferably only one - obvious way to do it” .
IMHO, this is a double-edged sword and I wonder how much we are sacrificing in some cases by treating it as “one size fits all” - which I don’t think it’s just 1% - not in my experience btw; or perhaps I’m finding myself in your 1% too much 
.
In the end, there’s no silver bullet, but I think this could still be achieved if instead of having no options, we could have opinionated defaults for the majority of cases as well as the ability to change them.
Yes, there are no silver bullets, but only tradeoffs. But requesting changes to the tradeoffs made on the existing formatter won’t necessarily make it more of a silver bullet as well. It will only make it more usable tool for some people by trading in the usefulness others see in the tool.
Yes, true and true. The thing is, allowing people more freedom to configure the formatter rules won’t cancel out the benefits we already have. My point is that standards should be opt-in.
Since we are already not required to use the formatter at all, I think it wouldn’t hurt to make it more configurable overall. Generally speaking, there will never be an amount of configuration that fits 100% of all the cases as well as lack thereof.
As you said, there are only tradeoffs.
You can write plugins for the formatter. For example, a trailing comma can be added by the freedom formatter.
It is kind of annoying committing to a library that uses their own personal style as it is just another thing to think about that you don’t normally have to bother with.