[gentoo-dev] Re: [PATCH eutils] Introduce run_in_build_dir() used in a few ebuilds.

[Duncan]

Mike Frysinger posted on Mon, 14 Jan 2013 17:09:51 -0500 as excerpted:

>>> +	[[ ${BUILD_DIR} ]] || die "${FUNCNAME}: BUILD_DIR not set."
>>
>> really should use -n there
>
>> Doesn't matter.
>
> the point wasn't "will it work".  it's more "how easy is it to glance at
> code and know what it is doing".

Indeed.  But arguably standalone [[ ${var} ]] tests ARE easier to "know 
what it doing."  

Consider:

1) The [[ $var ]] case is exactly one of one.  There's no misinterpreting 
it.  Even if you don't know the rule by rote, given that it's a boolean 
test on a string, there's logically only one way to parse it.  No 
mistakes to make.

2) By contrast, -n is only one of a whole list of -X style tests, and one 
must stop and think, "Let's see... Oh, yes, -n was non-null."

3) The situation in #2 is even worse than it might be due to the  
standalone alternative, making -n (and -z, #4) far less common than they 
would be otherwise.

4) You are arguing the "at a glance" position, but didn't even MENTION 
the needlessly negated logic of [[ -n $string ]] || ... , which could be 
rewritten to avoid the || negation as [[ -z $string ]] && ...

5) [[ ]] is already a bashism while the standalone string test is common 
shell.  Surely you're not arguing that people familiar enough with the 
[[ ]] || construct to parse it at a glance can't equally capably parse 
the a standalone string test, given its use in non-bash shell context as 
well.

6) If you're arguing for explicit, be consistent, with explicit
if/then, test, positive -z instead of negated -n logic... ::

if test -z "${BUILD_DIR}"; then die "${FUNCTNAME}: BUILD_DIR not set."



Obviously the example in #6 is taking it a bit far, but my point is, an 
explicit (if one-of-many) -z/-n test vs. the standalone (single-case) 
$string test really is personal preference.  You obviously prefer it one 
way, others (including me) prefer the other... for the very same reason, 
to us, our preferred way is instantly parsable, while the other way 
triggers "extra processing".

As such, IMO, "He who codes, decides." =:^)

(IIRC I did bring up the same thing, naturally arguing my standalone 
string test preference, in an earlier eclass proposal thread.  However, I 
believe I explicitly mentioned that I considered it a purely personal 
style thing and that others had the opposite preference, with to my 
knowledge no official gentoo coding style position taken on it.  Given 
that I had seen, I think you, bring up the point before, I was hoping 
someone would post the gentoo style-guide link proving me wrong, if there 
was one.  Given that nobody did so, I still believe it to be "he who 
codes, decides" territory.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman