I approved DIP1036e

[Dom DiSc]

On Sunday, 21 January 2024 at 11:13:41 UTC, Adam Wilson wrote:
> I think we need to specify what we mean when we say "low 
> quality contributions" as opinions on the subject vary 
> drastically. Quality here would be defined, in order, as:
> - Correctness (No obvious bugs, unittests pass, etc.)
> - Completeness (Does the code cover all know/specified cases)
> - Legibility (Can the average engineer understand the code? 
> This isn't the Obfuscated C Contest.)

I fully agree.

> Sadly, because it's easier bikeshed, especially when the 
> reviewer doesn't actually understand the code, most code 
> reviews turn into nit-picks focusing on sub-optimal but 
> ultimately insignificant deviations from the reviewers 
> stylistic preferences, all in the name of "legibility". The 
> single best way to derail a conversation on code reviews is to 
> bring up the topic of ... line length.

Oh please.
Everybody submitting a PR can easily run dfmt on it. This done 
there should be no more "too long lines", "multiple expressions 
in one line", "not correct indented code", "curly braces not on 
their own line", etc. pp.
If someone submit PRs without running dfmt, (s)he should be 
advised to do so. End of discussion.