Date: Tue, 8 Oct 1996 14:33:59 BST
Reply-To: Chris_B_Long@SANDWICH.PFIZER.COM
Sender: "SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU>
From: Chris_B_Long@SANDWICH.PFIZER.COM
Subject: Re[2]: 'Proper' use of IF-THEN-ELSE (was IF-THEN-ELSEs in a
Bruce,
I'm going to have to disagree on a couple of points... :-)
If multiple conditions are required, the first option should always be
to use a select statement, as you suggest. Obviously, this can only be
used when we are only concerned with equality tests on a single
variable, so is not always possible.
In fact, SAS doesn't place this restriction on the use of SELECT,
although what you say is true of C (in C, the WHEN comparators *must*
be constants, and these are compiled into a look-up table in the
executable. SAS seems to interpret SELECT as nested IFs!). Try:
163 data _null_;
164 i=10;
165 j=20;
166 select;
167 when (i=9) put 'S1';
168 when (sqrt(j) < 4) put 'S2';
169 when (i+j > 25) put 'S3';
170 otherwise put 'S4';
171 end;
172
173 i=10;
174 j=15;
175 select;
176 when (i=9) put 'T1';
177 when (sqrt(j) < 4) put 'T2';
178 when (i+j > 25) put 'T3';
179 otherwise put 'T4';
180 end;
181 run;
S3
T2
As for using sequential IF groups (with no ELSEs) as you suggest - IMHO
it's a very good example of very bad programming. (No offence meant :-)
If a set of mutually-exclusive conditions exist, they should be coded as
such, i.e. using an ELSE statement. This is _always_ easier to read,
particularly when sensible indenting is used, and will give, in your
examples, an average 50% reduction in execution time for that perticular
bit of code.
I can't agree that nested IFs are easier to read, but this is
obviously a subjective thing anyway. Re the execution times, I agreed
in my original post that nested IFs are often faster, but the
proportion is *extremely* dependent on the input data, and 'an average
50%' is a bit sweeping! And of course, in SAS programs the execution
time of individual data step statements is likely to be negligible
compared to the overhead of all the disk I/O that's going on. I would
generally prefer to code for (my version of) clarity first, and only
write less-clear, faster code when execution time is a sufficiently
important factor in the design spec.
In addition, the possibility of programmer error is significantly
reduced and readability increased.
For example: when giving SAS training, I often see students coding
multiple IF statements where several can be true, leading to one
statement being superceded by another. Lots of head-scratching ensues.
When I insist on them coding with the ELSE statement, they nearly always
get it right first time, as they have to think the logic through. If
there _are_ still errors, it's much easier to trace what's happening, as
a given outcome will only be the result of one, not several, sets of
statements.
Well, ok, but it sounds like they are finding the correct solution
more by being forced to 'think the logic through' than by using ELSE
per se.
As far as nesting is concerned, a structured programming approach will
reduce the need for this significantly. Although I accept that on
occasions deeply-nested IF-THEN-ELSE coding is required, if it is seen a
lot in an individual's programs, it's usually a sign of a bad design.
Agreed - and it will be seen a lot in your students' code! Surely you
would agree that one should emphasise good design before emphasising
the use of ELSE where it may not be necessary?
(I should perhaps repeat that my original post related *only* to
mutually-exclusive conditions).
Of course, this is assuming that a program is _designed_ in the first
place, which, as we know, is often not the case. :-)
No comment :-)
Bruce
