>>>Also agree about the exit point. You are using return as a way of breaking out of a process when you hit a certain point. Not a good idea. Much better to set variables at each stage ( if you are checking for bad conditions there may be more than one. Even in testing it would be good to find out about all of them on one pass)
>>
>>I must say that I find this 'one exit point' mantra seems to be confined to ex-VFPers :-}
>>
>>Here's what 'Code Complete' (which is pretty much language agnostic) has to say on the subject:
>>
>>"Use a return when it enchances readablility.
>>In certain routines, once you know the answer, you want to return it to the calling routine immediately. If the routine is defined in such a way that it doesn't require any further cleanup once it detects an error, not returning immediately means that you have to write more code"
>>
>>The accompanying example has three return statements in a method with five lines of code...
>
>He also says, "Minimize the number of returns in each routine It's harder to understand a routine when, reading it at the bottom, you're unaware of the possibility that it returned somewhere above. For that reason, use returns judiciously - only when they improve readability." (emphasis his)

No argument with that - but the thrust of the section is to demonstrate cases where multiple returns can enhance readability.

>The five-line example he gives is literally trivial, and isn't worth refactoring to a single exit point. IME that type of routine is not common in application or user code, possibly more so in frameworks or where absolute performance is important.
>

There are other, somewhat more realistic examples.

>Rather than the ( IMO ugly ) "guard clauses" he shows in the subsequent examples, I prefer something like this - call it a "guard method" perhaps:
>

>errorStatus = OKToDoStuff( parameters )
>
>If errorStatus = FileError_OK Then
>  * do stuff, also setting errorStatus
>
>End if
>
>* RETURN errorStatus here
>

>* OKToDoStuff( ) contains all the clauses in one place, and is easy to maintain while not affecting
>* the readability of the main routine
>

Maybe a matter of taste :-}
I prefer (find more readable) the guard clause approach.