Send me your list of D gripes and wishes

[Joseph Rushton Wakeling]

On Saturday, 31 December 2022 at 08:56:34 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> 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

OK, understood.  (It wasn't 100% clear from your previous post 
that you were envisioning one follow-up patch on top of the PR, 
as opposed to modifying patches in the PR.)

> You've got the problem right there. There is no tool to run 
> locally. Its mixed between a few different CI runner types.

Yeah, I see why that would be very painful.

What I'd like to suggest is that, regardless of what one does or 
doesn't do during CI, the absence of a single tool for checking 
or fixing style is the crux of the problem.  Whatever CI does or 
doesn't do, it's IMO useful as a developer to be able to check 
one's own code for style correctness, before submitting in a PR.

So it seems to me that the best way forward here is to make sure 
that all the wanted style checks _can_ be carried out by a single 
tool, or at least by a well defined set of tools with 
standardized configuration.

There are good examples in other languages.  I've historically 
preferred tools that just define what's objectionable rather than 
what's correct (if that makes sense), so there is still an amount 
of flexibility for the developer to write code as they wish, but 
since I discovered the Python tool 
[`black`](https://black.readthedocs.io/en/stable/), I think it's 
clear that it's at least _possible_ to craft a deterministic 
formatting tool that consistently produces good looking code.

What's particularly nice about that tool is that it can be run to 
edit code in-place, or it can be used in a dry-run mode which 
outputs a patch showing what would have been changed (with exit 
code 0 if that's nothing, or 1 if changes are required).

Where CI for my own projects is concerned, I've preferred to use 
the dry-run mode and throw it back on the PR author to actually 
_make_ the fix -- on the grounds that the PR author should be in 
control of what code changes, but also because it's 
straightforward to follow what changes are wanted, and equally 
trivial to run the tool locally to make them.  But obviously one 
could use the same tooling to append a style-fix patch to a PR, 
if that was considered desirable.

> 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!

I completely agree that we want to eliminate this kind of 
uncertainty.  I just think that to achieve it we need a 
well-defined tool which can be run locally as easily as in CI.

Python tooling is particularly instructive as a good point of 
reference, because there are other tools (e.g. 
[`tox`](https://tox.wiki/en/latest/)) which make it very easy to 
run a range of different checks (style, linter, test suite, ...) 
in a standardized way, via a single command.

Of course, it's not like people haven't already tried (`dfmt` 
etc.).  It just seems to be hard to sustain the momentum to 
implement and maintain such tools for D :-(

I'll mention some of these thoughts in the feedback I plan to 
write to Mike.