1-line idiom to replace if blocks

[James J. Besemer]

Y2KYZFR1 wrote:

> It does not show how clever you are, just how lazy and inconsiderate
> you are. I have fired people for less than this personally!

Then I'd say you're lucky if you haven't been sued for wrongful termination. 
     ;o)  Or perhaps you're luckily not subject to all the same rules that 
constrain managers in the US.

In the scheme of things, your basic inline choice construct/idiom is no more 
complicated or confusing than Python's and/or operators, array subscripting 
or dozens of other common features.  Most of us appreciate the extra 
generality of Python's and/or operators returning their arguments instead of 
a boolean result but I bet it is one of a number of minor stumbling blocks 
for many newcomers.  As shown by the common replacement idiom, inline choice 
is barely more than combining and/or in the proper order, so what's the big 
deal?  I mean, we're not talking anything approaching "Duff's Device" level 
of obscurity (http://info.astrian.net/jargon/terms/d/Duff_s_device.html).

In decades of programming I have found choice in data to be every bit as 
natural and useful as choice in control flow.  Often your data divides into 
more than just two pieces and you use an array but choosing among two sub 
expressions arises commonly enough to justify its own operator.  If the 
construct is implemented, taught, learned and properly used along with all 
the rest of the language then it is no more obscure or difficult for 
beginners or maintainers than hundreds of other subtleties typically found in 
any robust programming language.

I hasten to add, that whenever I do have occasion to use inline choice, I 
always fully parenthesize and "properly" indent the sub expressions, for 
maximum clarity:

     targetVar1 = ( condition1
                      ? ( condition2
                          ? result1
                          : result2 )
                      : result3 )

This convention preserves the notion that the first token on every line is a 
big clue as to what's going on with the rest of the line and that you can see 
the overall structure from the indentation.  (Some might prefer an 
alternative style where the trailing ')' lines up with the corresponding ':'.)

Frankly, I find that verbosity in and of itself does not necessarily increase 
  the clarity of code and more often it's actually harmful.  The fact that 
the Python equivalent of the above expression is more lines and more typing 
does not really add to the clarity of expression (except if you happen to be 
brainwashed to see things only that one way).

	if condition1:
	    if condition2
                 targetVar1 = result1
             else:
                 targetVarl = result2
	else:
	    targetVar1 = result3

In fact, I would argue that inline choice actually increases the clarity of 
the source code because it emphasizes that "targetVar1" is necessarily the 
single target of all possible sub expressions.  In the if/else form the 
reader has to visually verify that the target variables are all the same.  In 
my experience, one thing that best serves maintainability is to factor out 
common code wherever possible.  That way you avoid in advance the error prone 
process of having to make identical changes to parallel sections of code. 
Because there's a material savings even at the single statement level was one 
reason for adopting augmented assignment.  But the if/else form forces you to 
break this rule.

More importantly, by factoring out the redundant references to the target 
variable the inline form prevents a class of common errors.  E.g., if you 
look closely you'll find a subtle bug in the above if/else example.  This 
typo would be IMPOSSIBLE to make with inline choice.  Thus the supposedly 
"more readable" form tempts you to make these kinds of mistakes.  And this is 
a class of errors that easily go undetected in a declaration free language 
like Python.

So to flatly claim that the if/else form is superior to inline choice is 
simply untrue.  From the big picture standpoint, inline choice is equally 
useful and understandable.  Programmers can be trained to use and recognize 
both forms as easily as just the one.  Now, it's valid to say you prefer 
if/else as a matter of personal taste.  No accounting for taste.  As a 
manager, you can even enforce whatever standard you want in your coding 
style.  But even then, I think this view more often than anything else simply 
is a reflection of prejudice against the C/C++ family of languages.

Finally, I acknowledge that within the context of Python (which lacks such a 
construct) and within the context of the Python community (who, for whatever 
reasons, have decided to eschew the idiom) the earlier, milder words of 
discouragement on this thread may be appropriate.  And for the record, I am 
not (in this note) advocating any change to Python.

But Jeeze Louise -- FIRING people for employing a 1 line idiom, one that is 
asked for on this list about once every 2 weeks?  It must be awfully easy to 
recruit and retain good programmers where you live.

Regards

--jb

-- 
James J. Besemer		503-280-0838 voice
2727 NE Skidmore St.		503-280-0375 fax
Portland, Oregon 97211-6557	mailto:jb at cascade-sys.com
				http://cascade-sys.com