# \[Dream\] Towards standard source code formatting

**URL:** <https://discourse.haskell.org/t/dream-towards-standard-source-code-formatting/7756>\
**Category:** Uncategorized\
**Created:** [October 2, 2023, 12:08pm UTC](https://discourse.haskell.org/t/dream-towards-standard-source-code-formatting/7756 "2023-10-02T12:08:14Z")\
**Posts on this page:** 15\
**Page:** 2

<div class="post-metadata">

**Author:** ![alanz](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/alanz/32/678_2.png) [@alanz](https://discourse.haskell.org/u/alanz)\
**Post date:** [October 2, 2023, 7:07pm UTC](https://discourse.haskell.org/t/dream-towards-standard-source-code-formatting/7756/21 "2023-10-02T19:07:48Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![BardurArantsson](https://avatars.discourse-cdn.com/v4/letter/b/8dc957/32.png) [@BardurArantsson](https://discourse.haskell.org/u/BardurArantsson)\
**Post date:** [October 2, 2023, 9:22pm UTC](https://discourse.haskell.org/t/dream-towards-standard-source-code-formatting/7756/22 "2023-10-02T21:22:05Z")

</div>

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.)

---

<div class="post-metadata">

**Author:** ![BardurArantsson](https://avatars.discourse-cdn.com/v4/letter/b/8dc957/32.png) [@BardurArantsson](https://discourse.haskell.org/u/BardurArantsson)\
**Post date:** [October 2, 2023, 9:26pm UTC](https://discourse.haskell.org/t/dream-towards-standard-source-code-formatting/7756/23 "2023-10-02T21:26:03Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![alanz](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/alanz/32/678_2.png) [@alanz](https://discourse.haskell.org/u/alanz)\
**Post date:** [October 2, 2023, 10:29pm UTC](https://discourse.haskell.org/t/dream-towards-standard-source-code-formatting/7756/24 "2023-10-02T22:29:39Z")

</div>

> [@BardurArantsson](#):
>
> 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.

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

---

<div class="post-metadata">

**Author:** ![george.fst](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/george.fst/32/4933_2.png) [@george.fst](https://discourse.haskell.org/u/george.fst)\
**Post date:** [October 2, 2023, 10:59pm UTC](https://discourse.haskell.org/t/dream-towards-standard-source-code-formatting/7756/25 "2023-10-02T22:59:22Z")

</div>

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.

> <https://github.com/fourmolu/fourmolu/issues/46>
>
> \[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
> \`\`\`

---

<div class="post-metadata">

**Author:** ![tomjaguarpaw](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/tomjaguarpaw/32/1230_2.png) [@tomjaguarpaw](https://discourse.haskell.org/u/tomjaguarpaw)\
**Post date:** [October 3, 2023, 6:53am UTC](https://discourse.haskell.org/t/dream-towards-standard-source-code-formatting/7756/26 "2023-10-03T06:53:35Z")

</div>

> [@BardurArantsson](#):
>
> 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.)

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](http://h2.jaguarpaw.co.uk/posts/git-rebase-conflicts/).

---

<div class="post-metadata">

**Author:** ![tomjaguarpaw](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/tomjaguarpaw/32/1230_2.png) [@tomjaguarpaw](https://discourse.haskell.org/u/tomjaguarpaw)\
**Post date:** [October 3, 2023, 8:56am UTC](https://discourse.haskell.org/t/dream-towards-standard-source-code-formatting/7756/27 "2023-10-03T08:56:30Z")

</div>

FYI it seems that brittany may actually be maintained: [tomejaguar comments on Good Haskell code formatters?](https://old.reddit.com/r/haskell/comments/16y5gcb/good_haskell_code_formatters/k393zso/)

---

<div class="post-metadata">

**Author:** ![unorsk](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/unorsk/32/3144_2.png) [@unorsk](https://discourse.haskell.org/u/unorsk)\
**Post date:** [October 3, 2023, 8:56am UTC](https://discourse.haskell.org/t/dream-towards-standard-source-code-formatting/7756/28 "2023-10-03T08:56:43Z")

</div>

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 🙂

---

<div class="post-metadata">

**Author:** ![Vlix](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/vlix/32/1551_2.png) [@Vlix](https://discourse.haskell.org/u/Vlix)\
**Post date:** [October 3, 2023, 4:33pm UTC](https://discourse.haskell.org/t/dream-towards-standard-source-code-formatting/7756/29 "2023-10-03T16:33:05Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![wiz](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/wiz/32/2408_2.png) [@wiz](https://discourse.haskell.org/u/wiz)\
**Post date:** [October 6, 2023, 1:14pm UTC](https://discourse.haskell.org/t/dream-towards-standard-source-code-formatting/7756/30 "2023-10-06T13:14:21Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Ambrose](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/ambrose/32/5672_2.png) [@Ambrose](https://discourse.haskell.org/u/Ambrose)\
**Post date:** [October 6, 2023, 1:26pm UTC](https://discourse.haskell.org/t/dream-towards-standard-source-code-formatting/7756/31 "2023-10-06T13:26:11Z")

</div>

> [@wiz](#):
>
> line-based diffing → diff-friendly formatting → tooling that optimizes for the wrong end of a stick

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”?

---

<div class="post-metadata">

**Author:** ![tomjaguarpaw](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/tomjaguarpaw/32/1230_2.png) [@tomjaguarpaw](https://discourse.haskell.org/u/tomjaguarpaw)\
**Post date:** [October 6, 2023, 4:31pm UTC](https://discourse.haskell.org/t/dream-towards-standard-source-code-formatting/7756/32 "2023-10-06T16:31:05Z")

</div>

> [@Ambrose](#):
>
> I haven’t really found a quippy term for it

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

---

<div class="post-metadata">

**Author:** ![Ambrose](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/ambrose/32/5672_2.png) [@Ambrose](https://discourse.haskell.org/u/Ambrose)\
**Post date:** [October 6, 2023, 4:33pm UTC](https://discourse.haskell.org/t/dream-towards-standard-source-code-formatting/7756/33 "2023-10-06T16:33:49Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![alanz](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/alanz/32/678_2.png) [@alanz](https://discourse.haskell.org/u/alanz)\
**Post date:** [October 6, 2023, 5:53pm UTC](https://discourse.haskell.org/t/dream-towards-standard-source-code-formatting/7756/34 "2023-10-06T17:53:30Z")

</div>

> [@wiz](#):
>
> line-based diffing → diff-friendly formatting → tooling that optimizes for the wrong end of a stick

I would love to see diffs being done with something like [difftastic](https://difftastic.wilfred.me.uk/) which does a syntax-tree comparison, so layout doesn’t matter.

---

<div class="post-metadata">

**Author:** ![wiz](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/wiz/32/2408_2.png) [@wiz](https://discourse.haskell.org/u/wiz)\
**Post date:** [October 7, 2023, 7:42am UTC](https://discourse.haskell.org/t/dream-towards-standard-source-code-formatting/7756/35 "2023-10-07T07:42:53Z")

</div>

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

[Previous page](https://discourse.haskell.org/t/dream-towards-standard-source-code-formatting/7756.md?page=1)