Hi! I’m wondering if I should use formatter of elixir. I have never used any formatters in past projects.
So do you use formatter? And why do you use it?
2 Likes
I still use the formatter even though I really really hate some of the things it does (like no trailing comma’s on multi-line things) just for consistency with what everyone else expects. I do the same with rust’s formatter and C++ formatting via clang and others as well. I may do some slight tweaks in configs (hard tabs instead of spaces because screw 3+width indentations when I’m in a terminal) when possible, but otherwise try to keep it as ‘vanilla’ as I can. It makes it easier for other people to look at and PR to your code.
8 Likes
For my Elixir, Rust, JavaScript, JSON and OCaml editing I use formatters even if I don’t like all of their decisions how things should look like.
Truth is, our code will be read by other people so I prefer to be a good citizen.
11 Likes
For me it’s just a question of habit, more using formatter, more getting used to it and more loving things it does.
4 Likes
I love using the formatter, and specifically format on save in my editor, because it allows me to see if my code is right as it happens. If I save my file and everything snaps into place, I know I did things right. If it doesn’t, I know that I have a syntax error somewhere in the code I just wrote. Saves me from flicking back and forth to the server and my editor.
11 Likes
Same, and I absolutely love it.
2 Likes
I use even though I don’t agree with every decision, but to maintain consistency. We also use mix format --check-formatted on CI to ensure the code is formatted.
7 Likes
yes. formatting is for computers to worry about, not me and certainly not a whole team. That’s the important part, the consistency.
ditto on using format-on-save to quickly let me know if I biffed it with a syntax blunder or something!
5 Likes
I do. I have it setup to run in VSCode on save and my team uses Committee to run it as a precommit hook.
2 Likes
You all have inspired me to start using the format-on-save Atom plugin!
4 Likes
Yes, absolutely. We even fail CI build if the code is not formatted. My code is formatted in my editor on save.
4 Likes
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.
5 Likes
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.
16 Likes
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 Likes
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 Likes
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 Like
… 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 Likes
@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 Like
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 Likes
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 Likes
