>>
>> Absolutely, however, with my personal coding standards, there are two rules
>> that I follow which make the work simpler than otherwise might be the case.
>>
>> First: No premature exits of iteration structures. If an exit is required
>> that's predicated on a logical condition, then a DO WHILE...ENDDO loop is
>> used.
>>
>> Second: Each module has one, and only one exit point, namely the last line.
>
>
Hi Patrick,
>
>i'm always interested to read your comments.

Thank you.

>i heartily agree with your implied philosophy that personal coding
>standards really go a long way toward producing error-free code.
>glad to hear that though (re)expressed.
>
>as for having one-and-only-one exit point ... i used to adhere to
>that policy also, but over time have adapted my technique.
>
>now, i always have a dedicated section at the beginning of a subprogram
>that as much as possible, validates all data used in that subprogram.
>(of course this cannot completely validate, when processing a table or
>cursor, but ...)
>
>it just got to seem, that the deep nesting resulting from combining
>the validation with the processing often made the code hard to read --
>to the point it became more likely to have logic errors.
>
>in short, to have several exits from a standard validation section
>amounts to having a single exit from validation, and seems worth
>it since it simplifies the processing section. and i know exactly
>where to look for different types of functionality in my subprogram.

It may be a bit harder to follow perhaps, but there are other benefits. For one, smaller modules are easier to understand, and therefore, maintain. For another, once the algorithm has been proven, any errors resulting in another module calling it means that the problem lies elsewheres. Thus, tracking down problems becomes easier since there are a limited number of possibilities.