On Monday, 26 December 2022 at 04:06:05 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 26/12/2022 4:57 PM, Paul Backus wrote:
>> I agree that the friction cannot be reduced to zero. I still think it is probably possible to reduce it to, say, 50% of its current amount, without compromising on quality.
>
> Here is a big one: remove the damn style checkers!
>
> Automatic format on PR and commit right back into remote branch.
>
> Problem solved. No more CI errors.

Genuine curiosity, because maybe you have experience with that that I don't: how would this work with multi-patch PRs?

I ask because, personally, I don't find CI style checks to be a problem, especially if there's an easy way to run a local tool to check and/or fix things on a patch-by-patch basis.  That way I can make sure that the code is both style-compliant and that it "reads" well for me.  OTOH I do have a bit of a problem with the idea of an external system rewriting my code for me, especially if the result is messy -- like a series of patches that violate code style followed by an auto-generated fix-the-style patch.

Maybe that's too fussy ... ?  But my experience has tended to be that when people entirely outsource style-compliance to external tooling, you wind up with a lot of quite ugly code and harder-to-follow patches.

On 31/12/2022 9:36 PM, Joseph Rushton Wakeling wrote:
> On Monday, 26 December 2022 at 04:06:05 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> On 26/12/2022 4:57 PM, Paul Backus wrote:
>>> I agree that the friction cannot be reduced to zero. I still think it is probably possible to reduce it to, say, 50% of its current amount, without compromising on quality.
>>
>> Here is a big one: remove the damn style checkers!
>>
>> Automatic format on PR and commit right back into remote branch.
>>
>> Problem solved. No more CI errors.
> 
> Genuine curiosity, because maybe you have experience with that that I don't: how would this work with multi-patch PRs?

I don't see how it would differ, the format is a new commit as part of the PR.

See: https://mskelton.medium.com/auto-formatting-code-using-prettier-and-github-actions-ed458f58b7df

> I ask because, personally, I don't find CI style checks to be a problem, especially if there's an easy way to run a local tool to check and/or fix things on a patch-by-patch basis.  That way I can make sure that the code is both style-compliant and that it "reads" well for me.  OTOH I do have a bit of a problem with the idea of an external system rewriting my code for me, especially if the result is messy -- like a series of patches that violate code style followed by an auto-generated fix-the-style patch.
> 
> Maybe that's too fussy ... ?  But my experience has tended to be that when people entirely outsource style-compliance to external tooling, you wind up with a lot of quite ugly code and harder-to-follow patches.

You've got the problem right there. There is no tool to run locally. Its mixed between a few different CI runner types. They are all simple tests, like end of line white space and all have less than desirable error messages that you have to track down deep in log files.

People (including myself) spend time having to figure out why the CI failed, rather than letting it fix any problems it encounters. It adds a failure mode to contributing, when we could eliminate it and have more consistent code as a result!

On 12/31/2022 12:36 AM, Joseph Rushton Wakeling wrote:
> But my experience has tended to be that when people entirely outsource style-compliance to external tooling, you wind up with a lot of quite ugly code and harder-to-follow patches.

True enough. I adjust the style based on what the particular sequence of code is doing. I doubt "good style" can be mandated. Note that D's style checker has a number of knobs that turn various checks off, and this is used in its checking of the compiler source files.

On Saturday, 31 December 2022 at 08:56:34 UTC, Richard (Rikki) Andrew Cattermole wrote:
> You've got the problem right there. There is no tool to run locally. Its mixed between a few different CI runner types. They are all simple tests, like end of line white space and all have less than desirable error messages that you have to track down deep in log files.

You can run the checks locally with `make -f posix.mak style_lint` (Phobos, druntime) or `./build.d style` (DMD).

When it comes to style, people are not going to be happy, no matter what you pick.

You don't need to put too much work into the set of rules due to this.

In our case we have declared what the style should be for the dlang/ repos. So... that's what the tool must do.

On Sunday, 1 January 2023 at 09:52:55 UTC, Richard (Rikki) Andrew Cattermole wrote:
> When it comes to style, people are not going to be happy, no matter what you pick.
>
> You don't need to put too much work into the set of rules due to this.
>
> In our case we have declared what the style should be for the dlang/ repos. So... that's what the tool must do.

I've been part of some C++/Python codebases which transitioned to enforced clang-format/black formatting and in the end it was a good decision. Turned out everyone's personal code style isn't so precious after all and with modifying a few rules in the formatter you can adopt a formatting style that is acceptable for majority of folks. Also, every sourcecode formatter allows you to opt-out of auto-formatting for blocks of code, which is useful for manual tables and alignment.

In my personal D projects I have set dfmt to run on each source code file save and never really had to worry about formatting. I just write whatever, ctrl+S and get a nicely formatted D code. I may disagree with the way it formats things sometimes, but I just accept it as a minor tradeoff for convenience.