>Actually, Viv, it's also us ex-COBOL'ers.

Could well be :-}
But UT is one of the few forums that has a lot of programmers who still, or previously, primarily used VFP.
When I look at the same subject being discussed on other .NET forums I see a much wider acceptance of the improvements to readability and efficiency that multiple 'returns' can provide in the right circumstances.

Best design practices were not cast in stone with inventions of structured programming......


>Structured Programming came along during the 1970's when COBOL code was dominant.
>In order to stem the flow of horrible code being produced, some savants got together and enunciated some principles under the heading of Structured Programming.
>
>Here's what Wikipedia says about it:
>
>"Structured programming is a programming paradigm aimed on improving the clarity, quality, and development time of a computer program by making extensive use of subroutines, block structures and for and while loops – in contrast to using simple tests and jumps such as the goto statement which could lead to "spaghetti code" which is both difficult to follow and to maintain."
>
>One of its basic tenets is that a module should have one entry point and one exit point.
>That did wonders for the maintainability of COBOL and as an IT manager at the time it solved many problems for me, so I probably have a bit of an excessive attachment to it.
>
>The fact that DBase followed most of the rules of Structured Programming was one of its many appeals to me.
>
>
>
>
>
>>>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...