>>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)

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.

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