[Dream] Towards standard source code formatting

alanz · October 2, 2023, 7:07pm

I have switched from being anti to being pro-formatting, after starting on a codebase that had machine formatting by default, and realising how liberating it is. Bang in some code anyhow, hit format and move on. No hassles (it works even better if the language uses braces and the like, rather than layout).

And I think the specific style of formatting being used is a red herring. The advantage comes from having a standard style, which can be quickly and easily applied. Whatever the style is does not really matter.

I believe when Elixir introduced a formatter as standard, they asked people to just use it for a year, then they would address feedback. By then everyone was used to it, and saw the benefits, and there wasn’t further conflict.

And if it is built into the tooling, different projects can choose different formatters. And I suspect over time a small set would become standard, accepted by people as “the way code looks”, and well maintained.

BardurArantsson · October 2, 2023, 9:22pm

Preface: My experience with auto-formatting is generally horrible (granted in a different language, namely Scala), because I’m the type of developer who tends to refactor a lot of shared code, because I tend to work on shared infrastructure code.

It’s horrible because it leads to absurdly large diffs (and hence git conflicts) because it will tend to re-flow code for no good reason. Now, Haskell is more resilient to this effect when using the whitespace sensitive syntax, but it’s not immune due to e.g. aligning ‘<-’ preferences (and similar wrt. [ and , placement for lists.)

The thing is: I wouldn’t have a problem accepting ‘arbitrary’ choices as long it wouldn’t lead to absurd headaches figuring out what changed when I have a merge conflict.

(This may ultimately be a problem with Git and similar line-based-conflict resolution, but git is the world we live in… and I happen to value git extremely highly when you want to maintain a high standard of source provenance, etc.)

BardurArantsson · October 2, 2023, 9:26pm

As I think you’re alluding to here… I don’t think there’d be any problem with a “format:” field in a cabal file specifying which (cabal-compiled) formatter to use. There might be something to figure out about which version (and its dependencies and such), but that should be figure-outable.

alanz · October 2, 2023, 10:29pm

I think the point of the ormolou formatting choices is to make them diff-friendly. Hence the extensive use of newlines

george.fst · October 2, 2023, 10:59pm

As a maintainer of Fourmolu, I have to admit that we (and Ormolu) sometimes split things across lines in ways which can be rather ugly and even make diffs worse by changing the indentation of whole blocks.

github.com/fourmolu/fourmolu

Allow more complex subexpressions to remain on a single line

opened 08:06PM - 07 Oct 20 UTC

georgefst

[This rejected commit](https://github.com/georgefst/monpad/commit/708897cfb5281b…3ef65ecce43106bd14e0c41622) demonstrates some of the remaining places in which I find Fourmolu's default style unpalatable. Essentially, where an expression is only multiline because it ends with a particular *multiline-friendly construct* (this is a bit vague, but definitely includes record update and construction. `case` and `\case` statements, multi-way-if, and probably list literals), I'd like to format the preceding part of the expression in single-line style. As an extreme case, we currently turn: ```hs f = g 1 2 3 4 5 R { a = () , b = () } ``` in to: ```hs f = g 1 2 3 4 5 R { a = () , b = () } ``` Which is unnecessarily indented (twice!), and has a lot of almost-empty lines. The only current sensible solution is to use a local binding. And that only solves the second issue. Unfortunately I'm not entirely convinced this option could be implemented simply or efficiently. ## Another example It rather annoys me that, while this is accepted, adding some leading operation can cause a whole block below to be indented: ```hs items <- for [1 .. 5] \i -> print i ``` ```hs items <- id <$> for [1 .. 5] \i -> -- note that `$` is special-cased - that wouldn't be reformatted print i ```

tomjaguarpaw · October 3, 2023, 6:53am

Interesting, I also refactor a lot of shared code that is formatted with Ormolu and I don’t really experience this as a problem. I’m not sure why that might be. Perhaps it’s because Ormolu is better for diffs than the Scala formatter you use. I never get “absurdly large” diffs with Ormolu (at least not large when viewing with git diff -w. Alternatively, it might be a difference in workflow. I tend to make “absurdly small” commits which tend to be easier to resolve when conflicts arise. Additionally I have a well-specified approach to resolving rebase conflicts.

tomjaguarpaw · October 3, 2023, 8:56am

FYI it seems that brittany may actually be maintained: tomejaguar comments on Good Haskell code formatters?

unorsk · October 3, 2023, 8:56am

I’d want to have a default formatter too
And I think that having a default code formatter would benefit almost everyone.

As a seasoned developer I’d rather be a little unhappy with the style picked for the project but not have take part in any of the discussions/wars around the code formatting.

Having a code formatter right out of the box would also make the whole user experience smoother. So we don’t have to install and updated fourmolu separately (or am I getting the idea wrong?). It will also make easier for editors to get auto-formatting enabled by default, because it’d be like if you have cabal, you have the formatter too.

PS I’m wondering what Go people think about code formatting since this is something they don’t think often about (I am guessing) I am not sure if they even have many options for how their code gets formatted

Vlix · October 3, 2023, 4:33pm

Just to throw in my two cents: yes, default formatter would be very much appreciated.

We’re using fourmolu and I feel like the newlines can be excessive, but on the whole the “keeping diffs to a minimum” aspect is what makes me like it the most.

wiz · October 6, 2023, 1:14pm

line-based diffing → diff-friendly formatting → tooling that optimizes for the wrong end of a stick

I’m so unhappy that the “default formatting” is so hostile to me and creeps up into my life like a steamroller from hell.

Ambrose · October 6, 2023, 1:26pm

This is a phenomenon that extends beyond formatters, I find.

I haven’t really found a quippy term for it, but it’s basically when people allow the limitations of their tools drive their technical decision making.

It’s the same thinking as, say, avoiding advanced types because they take longer to compile. Or always putting :: on the same line as a definition so it’s more greppable.

Not that either of those decisions are inherently bad or anything. But they also aren’t objective improvements despite sounding scientific and data-driven.

Is it just that the alternative’s benefits are less quantifiable? “You optimize what you measure”?

tomjaguarpaw · October 6, 2023, 4:31pm

It used to be called “putting the cart before the horse”.

Ambrose · October 6, 2023, 4:33pm

haha I think this is more like if you put the horse in the cart, handed it the reins, and dragged then cart yourself.

alanz · October 6, 2023, 5:53pm

I would love to see diffs being done with something like difftastic which does a syntax-tree comparison, so layout doesn’t matter.

wiz · October 7, 2023, 7:42am

Yeah, I’ve switched to difftastic too. Certainly a step in a right direction.