I don’t use it on any of my open source projects because the formatter writes less readable code than what I write and I’m the primary person who has to read that code. But I use it at work simply because everyone else tends to like it. So I just go with the flow.
keathley
dimitarvp
Why not go all the way? 
Have that in your aliases section of mix.exs:
check: [
"compile --warnings-as-errors",
"format --check-formatted",
"credo --strict",
"coveralls.html",
"dialyzer --format short"
]
Then just run mix check and voila, you almost have locally running CI.
17
kelvinst
I do use it everywhere. In the beginning I didn’t like some of the decisions, but really, I stopped discussing about code style preferences a while ago by just blindingly accepting whatever is accepted by most of the community. Having a default formatter is really a nail in the coffin for those discussions for me. After some time, you either learn to write code in a way that the formatter is going to make it look good enough for you, or get used to the style enforced by it.
7
wmnnd
I find that using the formatter just lightens your mental load while coding with Elixir.
As programmers, we can be tempted to obsess about every little detail in our code. Under normal circumstances, the appearance/formatting is one such detail - and mix.format simply takes care of that aspect. And I for one always welcome an opportunity to do less bikeshedding
4
paulanthonywilson
I am not fond of some of the defaults - @OvermindDL1 mentioned trailing commas - but I’m ok with those(*). I love being able to type something really untidily and have the computer fix it up.
I’ve format-on-save on VS Code. It doesn’t format on autosave (though maybe that’s on option that I’ve not noticed?) and also occasionally flakes out. To cover this I have an alias which I use in place of mix test
alias mtest='mix format && mix test'
((*) In contrast to the popular Ruby linter, RuboCop, which has a set of defaults which infuriate me every time I have to deal with them. mix format and mix credo fmw).
1
patrickdm
.. interesting observation.
Now I’m asking myself if that it implies that I developed some kind of preferences for specifics type of constructs vs others, depending on the visual results of the formatter doing its job and some subtle aesthetic taste of mine… 
.. like the little use I make of with despite the extent I like its purpose…
2
tensiondriven
@Papillon6814 I generally agree with what others have said; using a formatter is of benefit to others who read your code and generally good for the community. The benefit of standardization, for me, outweighs the need for personal preferences.
I believe there’s a way to disable the formatter for certain blocks of code in specific cases where you really want to do something nonstandard… I’ve done this with CSS linters, but I don’t know how to do it in Elixir-ls specifically.
1
chouzar
For personal projects I usually avoid it, I usually end up having blocks of code that grow too large in width and sometimes the formatter ends up indenting these in ways that make them less parsable.
There’s this excellent article by Brian Marick which talks about the value of tabular code:
2
Sebb
I love tabular code.
This
defp decode(addr_t(:ind), _dest, data) do
case data do
<<0::6, data::bits>> -> {:t_data_ind, nil, data}
<<0b01::2, seq::4, data::bits>> -> {:t_data_con, seq, data}
<<0b1000_0000::8>> -> {:t_connect, nil, <<>>}
<<0b1000_0001::8>> -> {:t_discon, nil, <<>>}
<<0b11::2, seq::4, 0b10::2>> -> {:t_ack, seq, <<>>}
<<0b11::2, seq::4, 0b11::2>> -> {:t_nak, seq, <<>>}
_ -> {:error, :invalid_tpci}
end
end
for me, is just way more readable than
defp decode(addr_t(:ind), _dest, data) do
case data do
<<0::6, data::bits>> -> {:t_data_ind, nil, data}
<<0b01::2, seq::4, data::bits>> -> {:t_data_con, seq, data}
<<0b1000_0000::8>> -> {:t_connect, nil, <<>>}
<<0b1000_0001::8>> -> {:t_discon, nil, <<>>}
<<0b11::2, seq::4, 0b10::2>> -> {:t_ack, seq, <<>>}
<<0b11::2, seq::4, 0b11::2>> -> {:t_nak, seq, <<>>}
_ -> {:error, :invalid_tpci}
end
end
but I know, that most people don’t like it, so it will never be possible to format Elixir-code like that. And that is a good thing. It’s important to have a common code style everyone can read. So I keep formatting my C files in crazy ways, because in C, everybody complains about your style anyway and there will never be any agreement.
11
OvermindDL1
Elixir’s formatter is specifically designed to not allow that, which yes is irritating, but I’ve worked around it by putting some things in strings and then just extracting it at compile-time, a bit wtfery when someone looks at the code but it’s better than my finely crafted math tables getting screwed up, lol.
Entirely agree with you!
3