>I'm bound to get a lot of stick over this, but here's my opinion (even though you didn't ask for it!!)
>
>There are certain situations where you have to be able to back out of code, as you cannot make a decision about (x at pos) and (x at (pos+n)) at the *head* of the loop, for instance, in parsers and compilers where you may be reading a stream. There is also nothing wrong with breaking a loop where there may be MANY termination conditions (making the terminating condition almost unreadable). The alternative would be to set various flags and exit that way, but this can lead to a lack of clarity. Human-readable source is for humans to understand: clarity should be a higher priority (for maintainable code) than forcing code to a particular structure to avoid certain logic structures. [Anyone like to guess who has been a maintenance programmer??]
>
>Sometimes, the first record of a set MUST be processed and the result of this processing must be repeated *identically* for the remaining members of the set, but this can only be determined by processing the first record. You can write
>
>do
>...processing...
>if lFinished
>exit
>endif
>enddo
>
>or
>
>...processing...
>do while !Lfinished
>...processing...
>enddo

How about

lFinished = .F.
do while not lFinished
...processing... && presumably sets value of lFinished
enddo

It could well be possible to imagine logic constructs that can be expressed in fewer lines of code utilizing EXIT, LOOP etc. In 15 years in the xBase biz I've also done my share of maintenance programming. In all that time I've never had to use EXIT or LOOP, or even wistfully thought to myself, "if I was willing to compromise my principles this code would be a lot easier". OTOH I have replaced EXIT and LOOP in other people's code in order to fix subtle and pernicious bugs.

EXIT and LOOP are perfectly legal (so far) and there's nothing stopping anyone from using them as they see fit. All I can relate are my experiences, and opinions based on same.

I think George Tasker hit the nail on the head in an earlier message: that he considers them the equivalent of GOTO in Basic - with all the problems that causes.

>
>
>You must repeat the ...processing... code identically in the loop (in example 2): if a change needs to be made to the ...processing... code, it needs to be made twice. If you CAN limit your code to a few lines, great, but it's not always possible. It might not be possible replace...processing... with a single function call - and if it's more than 1 line long, you STILL have the possibility of errors creeping in later.
>I have seen this SO many times, where either of the ...processing.. blocks has had code changed and the other has not. Give me the latter, it's clear and there is less chance of error. If you were writing code that would NEVER be changed nor be edited by somebody else, I'd agree with you: if the two structures are logically equivalent, choose the one that is clearest AND less likely to lead to future problems, where you won't interrupt the flow of thought of the person reading your code.
>
>
>
>
>>>>I agree entirely. I consider EXIT and LOOP to be bugs until proven otherwise :-) Almost without exception, it's an indication that the coder hasn't thought the logic through clearly, making the entire structure suspect.
>>>
>>>I think this statement would be better qualified. For DO WHILE loops, I _ususally_ agree. But IMO, EXIT and LOOP have valid uses in FOR EACH and SCAN loops.
>>
>>Hmmm... I've *never* had to use them in those constructs (or at all, for that matter). Are you saying there are times you *must* use them to implement logic, or that they might be simpler to use in some circumstances?