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