Hi Jim,

I agree that there might be constructs (and I admitt I use it) where a singel case never will be true.
But I will still use the because of the neat coding. Just to give you an example

DO CASE
 CASE expression
**
 CASE nextexpression
**
 CASE expression
**
 CASE vfp.setvar('lvVar',somefunction())
*will never be reached
 case expression_uses_lvVar
* and so on
otherwise
**
endcase

I do not realy like it, but sometimes the whole construct is more straight. And I like the way of using DO CASE to avoid to much RETURNS and IFs ... ::) And I hope you see the comment. This belongs to this place everytime I do so.

All what I say is, that it may all of that may be frustrating if one does not understand the original programmers intention. I feel frustrated be endless deep nesting that my printer couldn't catch too. And I use an indention of one single space.

Since too much depends on the context even a sentence like "trees cannot over jump Dogs tall" may be wrong.

If I argue that a seed is a young tree, and its method (!) to walk away is to be eaten by a bird and be dropped somewhere else (and for what else are fruits designed?), would you agree that the tree can jump?

So there is no right or wrong, there is only I like it or I like it not. But this is me. If one is rewriting somebodys code and find itself frustrated by the style then I would say this is human nature. There is a differnce if you do corporate work, then there should be a common sense in the use. But if comes to strict rules, it will be very hard. And the most frustrated will the brightest minds.

I've reached this days end now.
Could you do me a favor and explain your first sentence? I didn't catch the point. And this is frustrating.

Agnes
>Hi Agnes,
>
>First, I like your tag line(s) < s >!
>
>The essence of *my* problem is usage of a DO CASE to do "work" in the actual CASE statement AND always end up being a FALSE so that the next DO CASE executes too.
>
>Sure, the reader's brain will eventually get it, but probably (as has been the case with me) only after much frustration.
>
>I think it is pretty clear that a DO CASE is expected to ask/answer a "question" and not to do real "work"... in the corrupted use in fact THE real work AND in concert with the remaining DO CASE statements. DO CASE simply is not anticipated to do that so the (next) reader only looks for that as a last resort. (= frustration)
>
>We are talking about readability here, not ease of coding. An IF, even nested to 5 or 6 levels, conveys a certain intention and certain factors about the problem at hand. Yes, it can be accomplished with a DO CASE with fewer lines but the DO CASE also conveys certain things that are totally opposite to its actual usage in that case.
>
>If I wrote "trees cannot over jump Dogs tall" you could eventually figure out what I meant and I could say it's perfectly understandable to me so what's your problem < s >. Does that make me right? Why is it any different with programming?
>
>cheers
>
>
>>Hi Jim,
>>>I continue to contend that DO CASE's design was never to do as your top example shows ...
>>
>>PMFJI,
>>
>>but to use things in a way they are not designed to is that what makes life possible down here. If our anchestors stuck on that idea they would never had invented the use of open fire. Or do you realy mean something is originally designed to be cooked? ::) (If the last sentence harms somebodies religous feeling: apologies)
>>
>>For example a wire was originaly not invented to conduct a current. Or a computer to draw graphics on it.
>>
>>I even disagree that DO CASE is not designed to do it. DO CASE catches the first expression that evaluates to .T. and what else is the code doing?
>>I agree that a too tricky use of DO CASE might be very unreadable and I have seen code like
>>
>>

>>lnLoop=1
>>do while .t.
>> do case
>>  case lnloop=1 and some_function()
>>   lnloop = some_newval
>>  case lnloop=2 and some_other_function()
>>   lnloop = some newval
>>*...
>>  otherwise
>>   exit
>> endcase
>>enddo
>>*process lnLoop for return code ...
>>

>>AFAIK I saw this in a FoxTalk article ...
>>
>>And why should I waste my time if endless boring IF..ELSE..ENDIF if it goes that neat? If the reader got the trick (and he will) its much faster to read then IF nested to dead or superfluous expressions to hold it flat.
>>
>>And (just a 1€cent thought) if you use a DO CASE like in VB, PASCAL or the like you still can do things like
>>

>>lnLoop=1
>>do while .t.
>> do case
>>  case lnloop=1
>>   if some_function() THEN
>>    lnloop = some_newval
>>   else
>>    lnloop = some_other_newval
>>   endif
>>  case lnloop=2
>>*...
>>  otherwise
>>   exit
>> endcase
>>enddo
>>*process lnLoop for return code ...
>>

>>,even eleminating the Exit and place some expression instead of DO WHILE .T. wouldn't make it better here.
>>
>>But do you know that this looks close to the way a PLC will be programmed?
>>
>>So all what I say is that all that stuff it depends on the place of use and sometimes the brains of the reader. And my personal feeling is that over normalizing a database is as wrong as a single return (loop,exit) point that result in endless deep nesting. To deep nesting is hard to maintain too.
>>
>>I normaly have a bunch of RETURNS on top of a method that will check the input, then I will process (with or without loop and exit as needed because they are designed for it) and a return an the end.
>>
>>We can not ban every usefull command because somebody missuse it.
>>
>>I go that far to say that something like GOTO target has it goods
>>because something like the following is very easy to understand
>>(pseudocode)
>>

>>parameters;
>>lvOptional
>>if expression then
>> GoTo WeHaveParameter
>>endif
>>
>>*some hundred lines to get the value from somewhere else
>>
>>:WeHaveParameter
>>
>>*process
>>

>>is very clear.
>>
>>And one last.
>>
>>If somebody is unable to trace some simple constructs like EXIT or LOOP, how should he ever deal with the wonders of *_ASSIGN, *_ACCESS, BINDEVENT or even the events that vfp raises?
>>
>>Agnes