Re: [PATCH 2/3] t4216: fix broken '&&'-chain

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Jun 30, 2020, 19:48 UTC
Message-ID: <CAPig+cTYg6DggGRkCmFb2aKfj_3OysjMNXofqMSOuewRotrQaQ@mail.gmail.com>
In-Reply-To: <20200630190325.GB1888406@coredump.intra.peff.net>

On Tue, Jun 30, 2020 at 3:03 PM Jeff King <peff@peff.net> wrote:

Show 11 quoted lines

> [...] what are we improving, and why?
>
> The original code handled the fact that the file might not exist by not
> including its exit code in the &&-chain which leads to the function's
> return value. Your new code does so by putting it in the &&-chain but
> asking "rm" to ignore errors. Is one better than the other?
>
> I think so, but my argument would be more along the lines of:
>
>   - without "-f", "rm" will complain about a missing file, which is
>     distracting noise in the test log

Indeed, a nice detail when reading verbose test output; one less thing to distract the attention from the real/important problems.

Show 5 quoted lines

>   - once "-f" is added in to suppress that, we might as well add the
>     command to the &&-chain. That's our normal style, so readers don't
>     have to wonder if it's important or not. Plus it would help avoid a
>     broken chain if more commands are added at the beginning of the
>     function.

The bit about commands possibly being added at the beginning of the function probably deserves its own bullet point. I often (relatively speaking) cite that reason when asking people to &&-chain variable assignments at the beginning of a function.

    func () {
        a=1 &&
        b=2 &&
        ...
    }