Yes, but the example had only 3 tested conditions. Changing the number to
suit a method invalidates the original comparison. It's like 5+5 versus
5+5+5+5+5+5+5+5+5+5+5 whereby you change your method from adding to
multiplying.
If it's argued that every IF statement 'could' grow to a 'huge' number' then
throw away the IF alltogether and your program looks like this:
BEGIN CASE
CASE X=1
GOSUB 100
END CASE
Certainly compilable but distracting.
I agree, in the case of a long string of parsing, CASE is preferred. I write
tons of EDI parsers and they all case CASE.
In the big picture, especially in the example we are both working on, IF
statements generally conclude on one OR the other condition. If there's 3 or
more, and only one should prevail, then CASE wins.
My 3 cents.
Mark Johnson
----- Original Message -----
From: "Dianne Ackerman" <[EMAIL PROTECTED]>
To: <u2-users@listserver.u2ug.org>
Sent: Friday, November 30, 2007 10:38 AM
Subject: Re: [U2] Deep and long indentations vs multiple exit points
> Mark,
> Although I usually agree with you, this time I have to disagree. Using
> a CASE statement in this way seems a very clear way to handle something,
> especially when you're checking for a huge number of reasons to
> "disqualify" something from happening. Have you ever programmed the
> Federal Financial Aid calculations? They have tons of things to check
> for before allowing a calculation. In my opinion, something like
>
> BEGIN CASE
> CASE FIRST.DISQUAL.CHECK; NULL
> CASE SECOND.DISQUAL.CHECK; NULL
> ...
> ...
> CASE TWENTIETH.DISQUAL.CHECK; NULL
> CASE 1
> DO MONSTROUS CALC
> END CASE
>
> is much cleaner and easier to read (and modify every single year) than a
> huge IF-THEN statement!
> -Dianne
>
> MAJ Programming wrote:
>
> >IMHO, using CASE as a replacement for IF's is extraneous. Meaning a
harder
> >alternate than what should be the simpler form. CASE statements resolve
to
> >being IF statements when compiled anyway.
> >
> >CASE statements are best used for their original purpose. That is to
> >evaluate multiple conditions and only accept the first valid one and
provide
> >an easy way to not consider the latter tests. Thus, each separate CASE
> >statement should have the thought process of individually being used
instead
> >of just cascading all the negatives.
> -------
> u2-users mailing list
> u2-users@listserver.u2ug.org
> To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
