This is expected behaviour to keep formatting standard and predictable. If one clause is multi line all clauses are made multi line.

Breaking out the long lines into separate functions to keep the case clauses short is the right way. It’ll also make the code more understandable by using descriptive names.

elixir_style_guide#multiline-case-clauses

Ahh, that’s too bad.

to keep formatting standard and predictable

I think it’s better to say the formatter does it that way because it wants to. There’s nothing unpredictable or nonstandard about just creating a multi-line clause for clauses that are too long but leaving the others alone. In fact, compared to other languages that have such syntax, such as F#'s match or OCaml, it is non-standard to have a multiline clause force all others to not only be multiline but have a newline space between them.

In my opinion, this is the wrong choice by the formatter. It makes functions less readable, longer, and triples the newlines with no benefit. What’s interesting is that the formatter doesn’t even breakout the if expression into multilines, but I can force that by doing it myself. In fact, I originally did that myself before the recursive calls were in place, as I don’t like single line if expressions, and that’s when I found out about this formatter behavior. It was an even worse change then (without the recursive calls).

Breaking out the long lines into separate functions to keep the case clauses short is the right way.

I’m not sure I understand. Creating one-off helper functions for individual result expressions seems tedious and also distracting. Do you mean “into separate lines”?

using descriptive names.

I definitely agree, but fighting with the formatter here actually makes one prefer shorter names. I’d rather have shorter names than have to scroll to see a function definition.

elixir_style_guide#multiline-case-clauses

Ahh! It’s in the style guide! It gets worse. I’ve never seen that in other languages. Maybe it’s from Ruby (which I haven’t used)?

I understand the need for consistency and generally have no problems with the formatter, but it would be nice for some configurability for highly opinionated, non-standard choices that the formatter makes. (The other one that comes to mind is comments in pipelines.)

For now, I have shortened the function name, and that seems to be an okay compromise. It lets me keep each clause on a single line and things readable enough where the shorter name is no issue, and maybe even preferable. (I’m porting this code from a book, so I initially follow the book’s function names.)

All valid opinions. It’s probably very hard to make everyone happy with standard choices and I’ve just come to accept what the formatter does because it’s predictable for me, and I can just get on with the work.

There are probably other alternatives to running mix format, something that works through beautifier or its like, which can be configured to your liking. But as far as I can tell the position taken on the formatter mirrors that of elm-format

The benefits of elm-format:

• It makes code easier to write, because you never have to worry about minor formatting concerns while powering out new code.
• It makes code easier to read, because there are no longer distracting minor stylistic differences between different code bases. As such, your brain can map more efficiently from source to mental model.
• It makes code easier to maintain, because you can no longer have diffs related only to formatting; every diff necessarily involves a material change.
• It saves your team time debating how to format things, because there is a standard tool that formats everything the same way.
• It saves you time because you don’t have to nitpick over formatting details of your code.

Yea, I am in one of the stages of “formatter grief” at the moment. Although, I do wish there was some configuration for these opinionated stances for individual orgs, teams, or projects to settle on.

For now, I’m trying to move into the acceptance stage of formatter grief. I’m also building up so-called tricks that help me strike a balance between what I’d like vs what the formatter does. I’ll paste what I came up with tomorrow, and I think it’s a fine enough compromise.

I’ll take a look at the Elm docs you sent tomorrow. Thanks for those.

I think a better word here - and what @03juan actually had in mind - would be “consistency”. Granted, it’s consistency with it’s own rules which can be changed. But my take is that the fewer the rules the better.

Yes, this is the way. There are situations where no code formatter rules will make the code look good (“for most people ”) unless you refactor it. For me, your code is a good example of that. Shortening the function name is one of the approaches (you can have top level evaluate_contract and then eval). Refactoring the common parts would be another:

{op, left, right} when op in @binary_ops -> evaluate_binary_op(t, left, right, op)

I’d say this is all or nothing. You need to be quite opinionated when deciding which options should be configurable.

This is the way.

To add sth useful: What I’d like the formatter to do is, that when I shorten the too-long-line the cases are restored to single lines.