>Jim,
>
>I took this from your comments in the GLGDW thread...
>
>>Some people hate (with a capital H) nesting of IFs simply because they can't stand the indenting. I don't worry about how much indenting is done.
>
>Here is a tip as an alternate to nested IFs that I use just because it is easier for ME to follow:

>
>local llSuccess
>llSuccess = .T.
>DO CASE
>   CASE NOT 1st_Logical_Test
>       llSuccess = .F.
>   CASE NOT 2nd_Logical_Test
>       llSuccess = .F.
>   CASE NOT 3rd_Logical_Test
>       llSuccess = .F.
>   OTHERWISE
>       llSuccess = .T.
>ENDCASE
>RETURN llSuccess

>Just remove the "llSuccess = .F." lines above or the "OTHERWISE" clause depending on your preference. That DO CASE is the same as --

>LOCAL llSuccess
>llSuccess = .F.
>IF 1st_Logical_Test
>   IF 2nd_Logical_Test
>      IF 3rd_Logical_Test
>         llSuccess = .T.
>      ENDIF
>   ENDIF
>ENDIF
>RETURN llSuccess

It really is interesting how different people prefer different styles. Some of my preferences:

- I tend to avoid DO CASE because I use it and its equivalents in other languages seldom enough that I find it hard to remember whether, in a given language, CASE "falls through" or not. I had to look it up in VFP9 Help to remind myself that in VFP it does not :)

- Why do I not use it very often? For me it's because (perhaps surprisingly) I pretty much always use an ELSE with an IF...ENDIF. This, in turn is because I usually include at least a stub for debugging, a message for verbose-mode parsing routines etc. When working with complex logic I find it relatively straightforward to convert truth tables to nested IFs; I find it more difficult to do it correctly with DO CASE or even harder with nested DO CASEs. When future maintenance is needed I find it easy to "zoom in" to the correct branch in IFs in a "binary" fashion.

Your example above is very clean because it is perhaps the simplest case - it's equivalent to

RETURN 1st_Logical_Test AND 2nd_Logical_Test AND 3rd_Logical_Test

- Whenever I see DO CASE, I read it as "REFACTOR ME" ;) Here's a trivial example of what I mean - I've seen this sort of thing many times in maintaining other people's code:

* GetTaxRate
LPARAMETERS ;
  tcProvince

LOCAL ;
  lnRate

DO CASE
CASE tcProvince == "BC"
  lnRate = 0.07

CASE ...
  ...

OTHERWISE
  ...

ENDCASE

RETURN lnRate

In this case I would of course create a table with provinces and rates; the code then becomes

* GetTaxRate
LPARAMETERS ;
  tcProvince

RETURN SomeLookupFunction( tcProvince )

- I try to keep indenting to 3 or at most 4 levels in any given routine, and farm deeper logic out to subroutines. So I can usually read my own code :)