>Hi Walter
>
>>Hi mike,
>>
>>I´m one that tries to avoid multiple exits point as much as possible. One of the big motivations I find is that it generally produces more readable code and avoids issues with resetting the environment, whether or not using a clever class handling settings. Restoring settings is only one of the many things you might want to reset at the exit point. For example form properties are not that easy to handle. For example when a piece of code handles a lot of GUI changes, you might want to use Lockscreen to block the GUI updates until you´re done. Now this is a nasty one if you forget to reset it to false when you exit a procedure.
>>
>>

LPARAMETERS cVar
>>LOCAL lRet, cSafety
>>
>>IF VARTYPE(cVar) = "C"
>>   cSafety = SET("SAFETY")
>>   SET SAFETY OFF
>>
>>   * Some buisiness processing
>>
>>   lRet = SomeBusinessCondition AND DoSomething()
>>
>>   SET SAFETY &lcSafety.
>>ENDIF
>>RETURN lRet

>>
>>or with the use of the pushup class
>>
>>

LPARAMETERS cVar
>>LOCAL lRet, oSafety
>>
>>IF VARTYPE(cVar) = "C"
>>   oSafety = CreateObject("PushPop","SAFETY","OFF")
>>
>>   * Some buisiness processing
>>
>>   lRet = SomeBusinessCondition AND DoSomething()
>>ENDIF
>>RETURN lRet

>
>I would like to extend your example.
>
>Let's suppose there are 10 parameters
>
>

IF VARTYPE(cParm1) = "C"
>    IF VARTYPE(cParm2) = "C"
>        IF VARTYPE(cParm3) = "C"
>            IF VARTYPE(cParm4) = "C"
>                IF VARTYPE(cParm5) = "C"
>                    IF VARTYPE(cParm6) = "C"
>                        IF VARTYPE(cParm7) = "C"
>                            IF VARTYPE(cParm8) = "C"
>                                IF VARTYPE(cParm9) = "C"
>                                    IF VARTYPE(cParm10) = "C"
>                                        *some business processing.
>                                    ENDIF
>                                ENDIF
>                            ENDIF
>                        ENDIF
>                    ENDIF
>                ENDIF
>            ENDIF
>        ENDIF
>    ENDIF
>ENDIF

>
>The chunk of code that is represented by "some business processing" is not any more readable now is it? The whole tab thing is not the way humans are taught to read. It's only some programmers that are taught to read like that.
>
>

IF VARTYPE(cParm1) = "C"
>    RETURN .F.
>ENDIF
>IF VARTYPE(cParm2) = "C"
>    RETURN .F.
>ENDIF
>IF VARTYPE(cParm3) = "C"
>  RETURN .F.
>ENDIF
>IF VARTYPE(cParm4) = "C"
>    RETURN .F.
>ENDIF
>IF VARTYPE(cParm5) = "C"
>    RETURN .F.
>ENDIF
>IF VARTYPE(cParm6) = "C"
>    RETURN .F.
>ENDIF
>IF VARTYPE(cParm7) = "C"
>    RETURN .F.
>ENDIF
>IF VARTYPE(cParm8) = "C"
>  RETURN .F.
>ENDIF
>IF VARTYPE(cParm9) = "C"
>  RETURN .F.
>ENDIF
>IF VARTYPE(cParm10) = "C"
>    RETURN .F.
>ENDIF
>
>*some business processing.
>

>
>The clever pushpop classes allow more freedom to code in different ways. I'll take clever and freedom over fascism anyday.

I thought Walter made it pretty clear it was his own preference, others would vary. I didn't read it as his trying to force his views on anyone, he just provided a different POV. BTW for many Europeans, especially in countries that were invaded/occupied in WW2, "fascism" is a hot-button word - use with care.

Didn't we discuss multiple exit points a while back? In your example above I'd farm out the parameter checking to a new function, which I think would be less distracting to the reader.