Thank you, Richard. That is exactly what I was trying to illustrate.
I'm a big fan of Rexx stems and PARSE, and regularly exploit their power. But
there comes a time when one must eschew elegance (and perhaps some efficiency)
on behalf of the poor schmuck who will need to read, understand, and/or modify
your code later. Especially if that poor schmuck might be yourself.
That is the why, of the eleven "Fundamental Language Concepts" of Rexx
enumerated by Mike Cowlishaw (TRL, Part 1, Section 3) the very first is
"Readability". [Note to Original Poster: he also lists the use of mixed case
code as the first of the five components of readability. There is no excuse for
the readability of any Rexx program to be sacrificed on the alter of the 026
keypunch!]
So, by all means, code your compound condition IF. But when your logic becomes
convoluted and it misbehaves, Rexx allows you to restate your problem in a
clearer way. If that means coding a "Then Nop" because positive logic in your
compound condition makes it clearer what you are checking for, so be it. If
coding "If \Abbrev(...)" gives you the same clarity (and more user input
options) go for it. If coding "Select ... When ..."s lets you test multiple
disparate conditions while avoiding nested "If ... Then ... Else If ..."s, Rexx
is there for you.
Precisely because Rexx has such expressive power it can, more than most other
programming languages, reveal flaws in the problem solution before it ever gets
to the execution step. Just look for statements that don't scan well in
English. If your mother could read it verbatim and have some idea of what's
going on, it's probably okay.
One last point that no one mentioned to the OP: one of the joys of programming
in Rexx is the ease with which debugging is accomplished. The _very_first_
thing I would have done in his situation would have been to insert a "Trace ?I"
in front of the failing instruction. The output of an Intermediate trace would
have made obvious the logical flaw in his IF instruction.
With that, and there being no objection, I declare this thread closed.
Respectfully submitted,
-Chip-
On 7/9/08 15:54 Schuh, Richard said:
I think that the stem solution, below, should be taken in the spirit of
fun, as it was undoubtedly meant. It appears to have been an extreme,
absurd example of how one can "overcode" a solution. (Why do it in a
single statement if you can write a chapter in a book to do the same
thing?) Strunk and White championed precision, brevity and clarity in
business communications in "Elements of Style". Their advice applies to
programming as well to letters, notes, and e-mail.
