On Thu, Dec 19, 2019 at 6:18 PM Denton Liu <liu.denton@xxxxxxxxx> wrote:
> On Thu, Dec 19, 2019 at 05:52:56PM -0500, Eric Sunshine wrote:
> > [...] I'd rather see:
> > { cp repo.git/sharedindex.* repo.git/repos/foo || :; } &&
> > which is the idiomatic way this sort of thing is handled in existing tests.
> >
> > While it's true that it may look a bit cryptic to people new to shell
> > scripting, as with any idiom, it's understood at a glance by people
> > familiar with it. That bit about "at a glance" is important: it's much
> > easier to comprehend idiomatic code than code which you have to spend
> > a lot of time _reading_ [...]
>
> The reason why I chose to do this was because I found myself writing the
> above many times in (currently unsent) later test cases that I cleaned
> up. As a result, I felt like it could be wrapped up more nicely with a
> helper function. That being said, if you think that open coding the
> idiom looks nicer, I can reroll to inline it.
I wouldn't say that the idiom "looks nicer", but rather that it has
value specifically because it is an idiom, therefore it reduces
cognitive load (as explained above).
Idioms aside, the new function test_non_git_might_fail() may increase
cognitive load because the reader needs to remember its purpose and
behavior since it's a black box compared to the open-coded version,
yet adds no actual value. Compare that with, say, test_must_fail()
which not only adds value but would significantly increase cognitive
load if open-coded, thus is well justified. That's not to say that
one-liner functions can't necessarily have value; a well named
function or one which introduces an important abstraction may very
well be worthwhile, but I can't convince myself that
test_non_git_might_fail() succeeds in that way.
So, to answer your question, my preference leans toward open-coding this.
