I usually tend to look at the bottom of a method for the return. Regardless number of "ifs". I do lots of old fashion IF statements anyway. Maybe that's my problem. I never (well hardly ever) write an "if" statement without an "else". My DOS daze code ran faster with else structures. Example

if largument=.T.
   ... do something
else
endif

I have noticed the code of some others exhibit this "style". Maybe, because of my coding "style". a single return point makes sense.

Your argumant about readability is good. But a single return point, well - you don't have to read through the code cause 'you' know it's at the bottom.
My debugging excusions usually deal with a wrong value being returned, and not so much the return point.

besides the original code could have been a lot cleaner, without an "if" or a "with":

return !(!this.Something)

:-)


>Methinks you missed an important point...
>
>Let the subroutine have, say 40 more lines of code and let there be 2 more (keeping it low) additional IF statements at the 'base' level. With "only a single return" (at the end of the code) in force, where has the readability been improved by enforcing that rule? Where has any time - THE huge argument for code readability - been saved in reading that code while debugging something?... especially if it turns out that this routine is not implicated in the bug at hand.
>
>
>>It seems more readable this way:
>>

>>with this
>>if !.Something
>>   llReturnFlag=.f.
>>else
>>   llReturnFlag=.t.
>>endif
>>endwith
>>return llReturnFlag
>>

>>My suspicion is that short-cutting an encapsulation might bait a C5.