Hi Dragan,
Well, for me, this is DEFINITELY a case of personal preference...
*My* prference is to see an exit as soon as possible and I don't particularly care if such code has to have some 'cleanup' (or whatever) conditions coded each time.
To *me* this business of a single exit point at the end only adds to the length of code I have to read for nothing. It also is more open to error when revising the code.
I think that, to do it the way I prefer, one definitely has to bite the bullet of 'keep the typing as little as possible'. I do bite it, on the basis that what easier for me NOW may prove harder later for either me or someoen else.
[I feel similarly about nested IFs. I know that some people prefer to 'misuse' DO CASE in their place because that results in less typing. I feel that saving a few keystrokes 'now' is not worth the pain that likely will come later.]
cheers
>>Actually, that is not entirely accurate. By using push/pop classes you can code with more freedom. There are those that will say, you shouldn't have more than one exit point. You should have the freedom to code without petty rules. You should not have to worry about simple human mistakes, like forgetting to reset. There are fewer lines of code to write, so you should be able to code faster. In my example I'm showing that the push/pop class could also change the SET command. IMO, you are most likely pushing the value because you want to change it. I put the vartype check before the set safety. With the pushpop, I could accidentally put the vartype check after the pushpop createobject and it would still work. There could be a business requirement requiring an early exit.
>
>>
LPARAMETERS m.tcVar
>>IF VARTYPE(m.tcVar) # "C"
>> RETURN .F.
>>ENDIF
>>LOCAL m.lcSafety
>>m.lcSafety = SET("SAFETY")
>>SET SAFETY OFF
>>* ... some processing
>>IF somebusinesscondition = .F.
>> SET SAFETY &lcSafety.
>> RETURN .F.
>>ENDIF
>>DO SOMETHING
>>SET SAFETY &lcSafety.
>>RETURN>
>While I agree that the cSet class (which exists as a freebie in the CodeBook, and is inherited in at least one CodeBook-derived framework that I used) makes things simple, your example of an early exit is slightly wrong - the exit is not early enough. If you're exiting early, you should do so
before you change any SETtings:
>
>
LPARAMETERS m.tcVar
>IF VARTYPE(m.tcVar) # "C"
> RETURN .F.
>ENDIF
>IF not somebusinesscondition
> RETURN .F.
>ENDIF
>* now we're doing business, save settings and do it
>LOCAL m.lcSafety
>m.lcSafety = SET("SAFETY")
>SET SAFETY OFF
>* ... some processing
>DO SOMETHING
>* ...done, restore.
>SET SAFETY &lcSafety.
>RETURN>
>Of course, there may be other exits that may be required during the business part, but these may be bracketed using a simple status variable:
>
lOK=SomeCheck()
>if lOK
> * do some more
> lOK={new check condition}
>endif
>
>if lOK
> * keep on processing
> lOK={another check condition}
>endif
>* done, restore>
>This way you don't have to have other exits but the early exits (before you disturb the settings) and one final exit (where you restore the settings).
