Obsession with line length and hideous formatting (am I writing elixir wrong?)

Line length is one of the few things you can configure on the formatter. If you feel the default is to short increase it.

Thanks, that’s not actually in the hex docs so I wasn’t aware. That should do for now!

Personally, 9 out of 10 times I see a function clause that spans multiple lines as a code smell. Ask yourself:

• Do you need all of that pattern matching in the function head?
• Can you match some in the body instead?
• Can you write a private guard to reduce matching or guard clauses?
• Can you use a case within a function (or all compiles down to a case anyhow)?

Agreed. I’ve come across “over-matching” to the point where it takes a second to figure out which matches are required for flow control.

handle_event is pretty ubiquitous so it’s not as big a deal, but I always write it like this:

def handle_event("save", %{"profile" => profile_params}, socket) do
  profile = socket.assigns.profile
  # ...
end

I feel that setting profile in the body is a lot less noisy than nested destructuring, especially when combined with capturing the whole value. My other reasoning is that the event name and param arguments are specific to the function itself whereas profile already exists in state, so destructuring it the head isn’t telling me anything new—I already know that I always have access to profile if I have a socket.

It’s all a matter of taste, of course, and totally up to you!

After playing with it a while, I really want to configure the formatter to never breakdown a long function head. I like how it formats other lines, so changing the line length breaks that preference. Is this possible?

Are you able to give examples of the last two in alleviating this issue? Thanks!

Thanks for the kick, I think this might be a case of me being new to the language. I find myself doing the same thing with “over-piping” the socket struct instead of making a regular function call with the socket as first param.

{:noreply, socket |> assign(:other, "other")}

# instead of

{:noreply, assign(socket, :other, "other")}

Think you mean subjective I actually find the formatted version easier to read. It’s easier for me to scan vertically than horizontally and I don’t like long lines. I tend to think one can get used to just about any formatting if you look at it enough, but also agree with others that too many matches in a function head can be hard to parse.

Sure thing!

1. Here’s an example of writing a private guard from Oban: oban/lib at main · oban-bg/oban · GitHub
2. Here’s an example of reducing the number of function clauses and minimizing the head size by matching with a case in the function body (it is from Oban Pro, so no link)

  def job_to_key(%{worker: worker, args: args}, partition) do
    case partition do
      %{fields: ["worker"], keys: []} ->
        with_hash({worker, nil})

      %{fields: ["args"], keys: keys} ->
        with_hash({nil, Map.take(args, keys)})

      %{fields: [_, _], keys: keys} ->
        with_hash({worker, Map.take(args, keys)})

      _ ->
        with_hash({nil, nil})
    end
  end

The formatter is something that I have a bittersweet feeling about and it’s perhaps the tool that I least like in the ecosystem. It’s great to keep a codebase consistent across teams if you don’t really want to think about it.

I hope for more configuration options in the future while keeping some opinionated default because I really care how my code reads. I also got my code butchered by the formatter a lot in the past because it doesn’t care about nuances as I do.

TLDR: It’s great for standardization, but the idea that a tool would decide how your code reads better than yourself is nuts to me.

There’s some value in those considerations overall if you want to increase readability in some cases, but I disagree with the premise of considering it as code smells. Mainly because there’s no real underlying issue in your code if you don’t follow this. It’s all a matter of preference on how you want to read your code. BTW, extracting code elsewhere is not always preferred for legibility.

That’s exactly my point, thanks @baldwindavid! Legibility is something really subjective and I think the main gripe some people might have with the formatter is that it’s not really flexible in the first place. It actually enforces very opinionated defaults which are also very subjective.