sodapopcan
Proposal: Have the formatter put `with`'s `do` on its own line
So after complaining about this for the third or fourth time on this forum, I figured I should make a proposal.
TL;DR
with can be hard to read sometimes as it can be hard to pick out where the clauses end and the body begins. While it’s syntactically valid to put the do on its own line, the formatter forces it back up on the same line as the last clause.
The Problem
While this is a very simple proposal, here are a truckload of words describing it in detail:
A non-insignificant number of people seem to have a problem with with. I think these people fall into two camps. The first has the people who are pipline obsessed who wrap their code or create macros that will make their everything they do pipeable. This proposal is not about this camp as that is a completely separate issue. The second has the people who very much like with as a construct but find the syntax a little clunky at times. This is evident by libraries like happy_with. While I don’t use any of these libraries myself, I am a member of this group.
For me the problem with with isn’t that I have to put commas or that I have to use <- (never understood this complaint) but simply that when there are more than a few clauses and the lines get a little longer—and especially when we aren’t necessarily matching on tuples—it is visually very difficult to find the do, ie, where the clauses end and the body begins. Having played around with it, I’ve found that the very simple act of putting the do on its own line completely solves this (for me).
I’m going to start by sharing this particularly hairy example from LiveBeats. I’m sure this will result in some saying, “Well I would find a different way to write this,” and I think I would try to too (but I haven’t) but this isn’t the point.
Here it is:
with version when version != :invalid <- lookup_version(version_bits),
layer when layer != :invalid <- lookup_layer(layer_bits),
sampling_rate when sampling_rate != :invalid <-
lookup_sampling_rate(version, sampling_rate_index),
bitrate when bitrate != :invalid <- lookup_bitrate(version, layer, bitrate_index) do
samples = lookup_samples_per_frame(version, layer
frame_size = get_frame_size(samples, layer, bitrate, sampling_rate, padding)
frame_duration = samples / sampling_rate
<<_skipped::binary-size(frame_size), rest::binary>> = data
parse_frame(rest, acc + frame_duration, frame_count + 1, offset + frame_size)
else
# ...
end
So yes, this is a little hairy, but I find that the meat of my negative reaction I get looking at this is that my brain can’t immediately identify where the clauses end and the body begins. The indentation makes it feel like someone just forgot to format which causes quite the visceral reaction in me along with a bit of mild panic! Sounds dramatic but I’m being sincere.
Here is it with do on its own line.
with version when version != :invalid <- lookup_version(version_bits),
layer when layer != :invalid <- lookup_layer(layer_bits),
sampling_rate when sampling_rate != :invalid <-
lookup_sampling_rate(version, sampling_rate_index),
bitrate when bitrate != :invalid <- lookup_bitrate(version, layer, bitrate_index)
do
samples = lookup_samples_per_frame(version, layer)
frame_size = get_frame_size(samples, layer, bitrate, sampling_rate, padding)
frame_duration = samples / sampling_rate
<<_skipped::binary-size(frame_size), rest::binary>> = data
parse_frame(rest, acc + frame_duration, frame_count + 1, offset + frame_size)
else
# ...
end
I still have that “Whoa, ok what’s going on here,” but I feel way calmer and more prepared/willing to get right to reading through it and figuring it out.
So here’s a much simpler example:
with {:ok, contents} <- File.read("/Users/andrew/passwords.txt"),
lines = contents |> String.split("\n") |> Enum.map(&String.split/1),
["My Bank Account", password] <- Enum.find(lines, fn [label, _] -> label == "My Bank Account" end) do
do_a_hack(bank_account, password)
end
But even here, while the indentation certainly helps, I still get that “looks like a botched formatting attempt” feeling, which is distracting.
I think is better:
with {:ok, contents} <- File.read("/Users/andrew/passwords.txt"),
lines = contents |> String.split("\n") |> Enum.map(&String.split/1),
["My Bank Account", password] <- Enum.find(lines, fn [label, _] -> label == "My Bank Account" end)
do
do_a_hack(bank_account, password)
end
Current Solutions
Using parens, the formatter leaves the following alone:
with (
{:ok, contents} <- File.read!(filename),
true <- String.contains?("foo")
) do
do_something_with(contents)
end
This is better but I think the non-paren version reads better. And of course having to add parens to such constructs is not very Elixiry.
Solution
Have the formatter put do on its own line. I’m specifically proposing that the formatter forces this style. I would be somewhat happy with (no pun intended but I’m pretty happy about it) the formatter accepting both styles, but of course that starts to degrade the usefulness of a formatter.
Thanks for reading!
EDIT: Just fixed some code sample errors and a small bit of wording.
Most Liked
christhekeele
I like this proposal.

I wonder if the current implementation of the formatter makes it hard to detect when a single-cause with would be able to fit do on the same single line as with, which is why it defaults to simply clinging to the last clause. Since, obviously, the below is undesirable:
with {:ok, contents} <- File.read!(filename)
do
do_something_with(contents)
end
A similar formatting outcome happens a lot with long function clauses so I imagine they use a similar heuristic, see:
Many guards
def multi_transaction_lock(multi = %Ecto.Multi{}, scope, id)
when is_atom(scope) and is_integer(id) do
multi
end
VS
def multi_transaction_lock(multi = %Ecto.Multi{}, scope, id)
when is_atom(scope) and is_integer(id)
do
multi
end
Or even, from the very same LiveBeats function
Much pattern matching
defp parse_frame(
<<
0xFF::size(8),
0b111::size(3),
version_bits::size(2),
layer_bits::size(2),
_protected::size(1),
bitrate_index::size(4),
sampling_rate_index::size(2),
padding::size(1),
_private::size(1),
_channel_mode_index::size(2),
_mode_extension::size(2),
_copyright::size(1),
_original::size(1),
_emphasis::size(2),
_rest::binary
>> = data,
acc,
frame_count,
offset
) do
with...
end
VS something more like
defp parse_frame(
<<
0xFF::size(8),
0b111::size(3),
version_bits::size(2),
layer_bits::size(2),
_protected::size(1),
bitrate_index::size(4),
sampling_rate_index::size(2),
padding::size(1),
_private::size(1),
_channel_mode_index::size(2),
_mode_extension::size(2),
_copyright::size(1),
_original::size(1),
_emphasis::size(2),
_rest::binary
>> = data,
acc,
frame_count,
offset
) do
with...
end
More generally, I’d personally prefer the do on its own line in all the above multi-line cases, under the philosophy that indentation is closely aligned with the lexical scoping of blocks.
do often delineates pattern-matching constructs (which have their own scoping rules) on the left from bound code on the right; and in multi-line cases having the do on its own line “resets” my mental expectations of the lexical scope when scanning code, which I think is an accurate mental model of these constructs.
I bet it is possible to develop a formatter extension that applies this rule to just multi-clause with expressions, or even to all multi-line do blocks as per my preference—I’d be interested to give such an extension a go, if anyone develops one to trivially preview how this proposal looks on real-world codebases.
smathy
My real point here is just that it’s likely that there’ll be people who feel strongly, and arguments and edge cases on both sides that will be difficult to accommodate.
I don’t have a horse in this race, so the following are just general thoughts:
-
The comma thing is the same issue with the trailing
doanyway, so that’s not a comparative negative for your new linedo. I rely on my diff tools to make any reordering of attributes easier to see, it’s a shame github doesn’t have a more reliable “color-words” implementation, but I generally review code locally anyway. -
My approach to reading code is no doubt heavily influenced by the fact that I started coding in an 80 column monochrome world. In fact more often than not the first step to reading any sizable source code was to send a print job off to the dot matrix.
-
I have been told I read code like a compiler.
-
Wide screens and editor tooling means that I really can’t relate to the feelings you’re expressing about readability difficulty. Ie. the two big messy original examples you showed look the same to me. I’m not unfamiliar with your position, I’ve heard it from many others, it’s just not something that impacts me. The only thing that threw me reading that first example was the missing
)in thelookup_samples_per_framecall. -
I’ve often wondered whether it might be a good learning exercise for developers to switch off all the color and helpers we’re so used to (reliant upon) these days, and just get some experience reading black and white source code.
-
I secretly wish I could convert the world to my way of thinking about this, because all discussions of style feel like bikeshedding to me. That “panic” you talked about hits me when I get invited to a meeting to discuss style

-
There are definitely some things which I believe are inherently hard for anyone to read, such as your
assign/2reordered attributes thing. Obviously big diffs where only indenting has changed fall into the same bucket.
tomekowal
I have another problem with the formatting of with. It is somewhat artificial and solved by tooling, but it is annoying from time to time. Functions between with and do are the only thing that is indent odd amount of spaces ![]()
This is annoying when I work with editors that have commands like indent that atumoatically put two spaces. Unlike if and case that work with one expression before do part, with is designed to work with many. So I’d actually see it like this:
with
expr1 <- func1()
expr2 <- func2()
do
expr3
expr4
else
:a -> a
:b -> b
end
smathy
Heh, I often say to devs who seem reluctant to “write tests” that every developer writes tests, the only question is whether you save them so you can rerun them.
I think it’s awesome how Elixir has that copy/paste from iex to test feature, whatever it’s called.
Ah, so you were. Yeah, I’m not sure I’ve found it exhausting, but I probably would if I was forced to persist with it, but my #1 complaint would be that I’m unproductive.
That process seems more achievable than going straight to TDD from the get-go. You’ve kind of done the “tinkering/playing around” phase I was talking about in my own process before getting into the TDD.
smathy
Yeah, my justification is that if they’re using terms that they have no idea about, then my answer really doesn’t matter:








