Should we lint, -wall and format our code base?

[alanz]

I have recently spent some time in the code base again.

I can't help noticing that I have several hlint and other warnings, as well as a variety of formatting styles. Format differences naturally occur with multiple contributors of course.

Given the growing size and number of contributors, I think it would be good to enforce an hlint config, as well as require compiles to pass -wall, or some agreed set of warnings. This could initially be done via a separate "allow-fail" CI build which we aim to bring into compliance overtime.

And perhaps we should agree to use a specific formatter, and format all the code with it.

[konn]

I can't help noticing that I have several hlint and other warnings, as well as a variety of formatting styles. Format differences naturally occur with multiple contributors of course.

And perhaps we should agree to use a specific formatter, and format all the code with it.

Even though I'm not a maintainer, but as a spare-time contributor, I strongly agree with this point!
While I tried to make some contributions to HLS, I have already broken the indent styles by accident for some times.
The changes are trivial in some cases so that one can manually re-order import list or adjusting indentation, but sometimes it becomes rather tedious to maintain formatting coherency in per-module manner.

As a contributor, I feel more comfortable if there is project-wide formatter configuration and we can just let HLS to invoke them automatically. That saves essentially unnecessary works both for contributors and reviewers, reducing noise from reviwing process, IMHO.

[alanz]

Contentious question: which formatter?

To my mind it should be one without requiring much config, or used with the default config.

[jneira]

Contentious question: which formatter?

What about making a poll? 😄
I am personally fine with any of them, and even i am not too disturbed with the actual situation (although agree in it can save time for all of us). I've found more useful the more semantic oriented -Wall and hlint.

[Ailrun]

I think in terms of reducing config, ormolu would be a good choice.

[peterwicksstringfield]

Reformat the entire code base with whatever format is chosen, then re-run it on each PR before the unit tests. If there are changes they can be automatically committed and the build restarted. So any successful build is a fixed point of the formatter. I don't think it matters which format is chosen, just so long as the computer is the only one who has to actually think about it.

Wall and hlint sound good too.

[ndmitchell]

The formatting inconsistency in Ghcide is significantly higher than most code bases, because it went through 4 evolutions and 4 authors before it even became public. I think whatever we do here should also be done in Ghcide too.

As a general rule, I think the more authors work on a code base, the more stringent you should be with warnings. I don't like Wall for my personal projects, but for something with as many contributors as this project, it seems necessary. For formatting, I'd really like an endorsement from someone who has tried it in anger and found it worked. Fourmulu would be my default, but the number of end users is still lower than I'd like.

[georgefst]

Fourmulu would be my default, but the number of end users is still lower than I'd like.

Well, I don't really know how to measure that but I'm sure it's not huge. GitHub stars would put us at about 10% of the popularity of Ormolu, Stylish and Brittany. But it's likely to be higher than that since we haven't been around long and people aren't inclined to go back and un-star tools they've stopped using.

Anyway, I'm using it on pretty much all of my projects now, including a small team at work. And at least one other company is using it, based on one of our merged PRs. I've been keeping notes of places where I feel the output could be slightly nicer, but at this point they're mostly very minor things inherited from Ormolu. Main one is a slight over-keenness to insert line breaks (which I've rambled about a little in this issue). But some people presumably like the current behaviour, based on the popularity of Ormolu and Elm-format.

[ndmitchell]

Anyway, I'm using it on pretty much all of my projects now, including a small team at work.

To me, that's enough to recommend Fourmulu (or if some people prefer Ormulu, have a debate between the contributors). Real practical use by a contributor trumps most other things.

[konn]

+1 for fourmolu, as our team had switched to it a month ago and it seems really useful to minimise diffs on Git, and allows us additional configurations.

[Ailrun]

@konn I'm not sure whether it will be helpful to allow more configuration in this case. As mentioned before, Current HLS has lots of contributors and styles, and leaving a space for configuration may lead to some unproductive debates about what should be the style of HLS.
I personally don't prefer Ormolu's (and similar) formatting style, but for some big project like this, I think their approach (un-configurability) is the right one.