Send me your list of D gripes and wishes

Richard (Rikki) Andrew Cattermole richard at cattermole.co.nz
Sat Dec 31 08:56:34 UTC 2022


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!


More information about the Digitalmars-d mailing list