I tend to use a mixed approach.

Some validations with early RETURN on the top of the function AND single exit point for the core of the function.

Nothing is fully black or white

:-)


>>Hilmar,
>>
>>How about "never say never"? Why try to say you'll never write a piece of code that has more than one exit point? I've seen examples where flags short-circuited large parts of a procedure. IMO it would have been easier to read down to where the flag was and find a RETURN instead. There'd be no reason to read beyond that. Using the flag, you'd have to look for what it short-circuits and read down to find a subsequent RETURN.
>>
>>
>>>I read somewhere that a function (or method) should have a single point of exit (RETURN). Is this considered a general design principle, that should usually be followed?
>>>
>>>I find that it is more complicated to code a function or method to have a single RETURN, but I also see that it may make cleanup (if required) easier.
>>>
>>>TIA, Hilmar.
>
>Yes. I find the multiple RETURNs easier to code in general. But I wanted to know whether there was a general consensus about this "principle" as some consider it. It turns out there isn't. Several respected experts say "use a single exit point" - and several others say "don't". I think I will continue doing what I have been doing until now: Use several exit points in many cases. Where this is too inconvenient (too much cleanup), design for a single exit point.
>
>Hilmar.