[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [PATCH 2/3] t4216: fix broken '&&'-chain
From:       Eric Sunshine <sunshine () sunshineco ! com>
Date:       2020-06-30 19:48:36
Message-ID: CAPig+cTYg6DggGRkCmFb2aKfj_3OysjMNXofqMSOuewRotrQaQ () mail ! gmail ! com
[Download RAW message or body]

On Tue, Jun 30, 2020 at 3:03 PM Jeff King <peff@peff.net> wrote:
> [...] 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.

>   - 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 &&
        ...
    }
[prev in list] [next in list] [prev in thread] [next in thread]