>Hi Jim,
>
>>I think there's been success in avoiding a general conclusion that EXIT/LOOP are evil commands that are never to be used.
>
>No absolute rule, Agreed,
>
>>The next phase may be to get people to avoid getting cold sweats when they are reading code that has a (some) EXIT/LOOP line(s) in it because all that does is prejudice the reader and so toughen his/her job. For (generally) no good reason.
>>
>>By the way I can't see ever agreeing that DO CASEs coded specifically to execute every CASE statement (faking a FALSE condition on each to make it happen) is EVER READABLE. IF your definition of readable is fewer indentations then you may think you have a winner, but in fact you don't. I bet that 98% of people debugging someone else's program expects that a DO CASE is testing for (more or less) independent conditions where 1 is EXPECTED TO BE TRUE. What you say is fine is totally contrary to the design intention of DO CASE and in my opinion is genuinely a cop-out from doing things properly. Just because DO CASE *can* be used that way does not make it reasonable to do so. Curious that you feel that you can successfully avoid EXIT/LOOP in your own code (and get worried when you see it in others) yet you happily use a construct exactly against it clear design intention! I'd say yours is one example of the definition of "readability" that could use some reconsideration.
>
>I don't quite get on what specific constructs you're talking about. However if clearly written I don't see a problem with constructs like.
>
>

>SELECT SentOrders
>SCAN
>    DO CASE
>        CASE NOT THIS.IsInVoiceReady()
>            Wait window "The invoice is not ready"
>
>        CASE NOT THIS.IsInvoideApproved() OR NOT THIS.ApproveInvoice()
>            wait window "The invoice is not approved"
>
>        CASE NOT THIS.SendInvoice()
>            Wait window "The invoice count not been send"
>
>        OTHERWISE
>            Wait window "The invoice has been send"
>    ENDCASE
>ENDSCAN

>
>The example above walks through all send orders. In the first two cases it checks on conditions if an invoice can be check or not, the third tries to send to the invoice. If not succesfull it launches the otherwise.
>
>the algorithm above uses both the strict order of the CASE statement execution to do its job and using functions to return a value. I can't see why this is not readable. In all honesty I think it is far more readable in a case where the actual implementation of the methods are in a long winded SCAN or DO WHILE where you everytime have to figure out what exactly it is supposed to do.
>
>

SELECT SentOrders
>SCAN
>    SELECT Client
>    LOCATE FOR Clt_pk = SentOrder
>    IF clt_RequiresCompleteOrderBeforeBilling
>        SELECT Orderlines
>        LOCATE FOR orl_ordfk = Sentorders.ord_pk AND NOT orl_send
>        IF FOUND()
>            ** not the whole order has been send while the client requires so
>            Wait window "The invoice is not ready"
>            LOOP
>        ENDIF
>    ENDIF
>
>    IF NOT SentOrder.ord_approved
>       ** Long algorith trying to approve order
>       IF NOT lApproved
>          wait window "The invoice has not been aproved"
>          LOOP
>        ENDIF
>    ENDIF
>
>    ** Long algorithm to send invoice
>    IF NOT lSend
>        Wait window "The invoice has not been send"
>        LOOP
>    ENDIF
>
>    Wait window "The invoice has been send"
>
>    .... other stuff
>ENDSCAN

>
>Again, whether we talk about DO CASE or LOOP and EXIT, readability and maintainability is in the hands of the programmer. Neither DO CASE or LOOP and EXIT gaurantee properly written code.

Well I heartily DISagree... your first is prettier but certainly is not more "readable" in the context of what the reader EXPECTS a DO CASE to be doing in program logic. In VB, for example, you cannot do what yours does, and I'd say for good reason!
In your second example your "*long algorithm here to..." is easily replaced by a function call. Same with your earlier stuff there.

I'd say that your original is sourced in an aversion to nested IFs and I'd say that aversion harms the code readability rather than helping it.

I continue to contend that DO CASE's design was never to do as your top example shows AND that most readers never expect to see one doing what you are doing. That itself makes its readability questionable. YOU expect/know its intentions but an outsider will read the code anticipating that ONE of the CASE statements will return true and so execute the code below it.
Just because something can be done does not mean it should be done. For instance, languages that have GO TO, JUMP, BRANCH, etc still have them but people simply do not use them to cross module boundaries.

cheers

>
>Walter,