Many of my PRs have been nitpicked. I just fix them, it's easier than arguing about it.

On 22/01/2024 1:35 AM, Dom DiSc wrote:
>     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.

Yes, that has been added to the PhobosV3 proposal by Adam.

I also suggested that we automate it as part of the CI. Because who has time to care about white space at the end of a line? No thanks.

On Sunday, 21 January 2024 at 17:37:41 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 22/01/2024 1:35 AM, Dom DiSc wrote:
>>     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.
>
> Yes, that has been added to the PhobosV3 proposal by Adam.
>
> I also suggested that we automate it as part of the CI. Because who has time to care about white space at the end of a line? No thanks.

Yes, yes, and yes. At work we have a linter that IS integrated into the CI pipeline, and a formatter that is NOT, for some unfathomable reason. Every time one of my PRs fails the CI pipeline because I forgot to run the formatting tool before pushing, I want to scream. Just automate it and a whole class of PR nitpicks/arguments disappears, and everyone is better off.

On Friday, 19 January 2024 at 00:20:36 UTC, Adam D Ruppe wrote:
> I unsubscribed from this forum, since I find it to make me angry and not lead anywhere productive, but people linked me to this so I'll give one more reply to set the record straight.
>
> There's a ST:TNG scene that comes to mind relating to all this:
>
> https://www.youtube.com/watch?v=Owyj_5TuHQw
>
> "It's not you I hate, Cardassian. I hate what I became because of you."

You are excusing the inexcusable, blaming it on someone else. Yes, I'm sure you endured months, years of frustration, which you've documented. You had options to address that problem, one of which you recently exercised. Behaving like a child who couldn't get his way was not one of them, at least one that reflects well upon you.

On Sunday, 21 January 2024 at 17:12:37 UTC, Walter Bright wrote:
> Many of my PRs have been nitpicked. I just fix them, it's easier than arguing about it.

I think, I said this one Discord a while ago, it’s usually so much quicker to just submit a cleanup patch/PR than trying to push the nits through the review of the main PR.

If it isn’t something substantial that the original author should be aware of, doing so is easier and will save everyone time.

On Sunday, 21 January 2024 at 19:20:21 UTC, Meta wrote:
> [...] I forgot to run the formatting tool before pushing, I want to scream. Just automate it and a whole class of PR nitpicks/arguments disappears, and everyone is better off.

What about code which is more art than craft?

    this(int a, int aa, int aaa, int aaaa, int aaaaa)
    {
            this.a = a;
           this.aa = aa;
          this.aaa = aaa;
         this.aaaa = aaaa;
        this.aaaaa = aaaaa;
    }

    double carefullyHandAlignedIndentation(double x________________________,
                                           double y________________________,
                                           double z________________________)
    {
        return 0;
    }

dfmt --brace_style otbs produces

    this(int a, int aa, int aaa, int aaaa, int aaaaa) {
        this.a = a;
        this.aa = aa;
        this.aaa = aaa;
        this.aaaa = aaaa;
        this.aaaaa = aaaaa;
    }

    double carefullyHandAlignedIndentation(double x________________________,
            double y________________________, double z________________________) {
        return 0;
    }

If you need to disable dfmt for a block of code, disable it.

https://github.com/dlang-community/dfmt?tab=readme-ov-file#disabling-formatting

```d
void main(string[] args)
{
    bool optionOne, optionTwo, optionThree;

    // dfmt has no way of knowing that "getopt" is special, so it wraps the
    // argument list normally
    getopt(args, "optionOne", &optionOne, "optionTwo", &optionTwo, "optionThree", &optionThree);

    // dfmt off
    getopt(args,
        "optionOne", &optionOne,
        "optionTwo", &optionTwo,
        "optionThree", &optionThree);
    // dfmt on
}
```