>Hi George,
>
>>If performance isn't an issue with the code, then don't, because you ultimately do harm to the readability. I've always maintained that, "If it ain't readable, it ain't maintainable." Further, I realize that I'll spend more time in maintenance and modification (updates, etc.) than anywhere else.
>
>IMHO, early outs are may be more readable:
>
>

if lCond1 or lCond2
>    *Get out now if not enough stuff
>    MessageBox('hey dummy!  You messed up')
>    return .f.
>endif
>
>*200 lines of Code
>
>return .t.

200 lines??? Did you read what I said earlier? More than 20 is a flag to me that the module isn't as cohesive as it needs to be. For example, I'm working on an in-process automation server. Including empty lines, properties, and continutations, there are 914 lines of code. Methods? 47 That's an average of 19.45 lines per method including the above. So in reality the amount of code lines is actually less.

The longest method in the most recent application that's in production is 75 lines. However, for me that's extraordinarily long.

And when is performance not an issue? ;-)

I know you're joking here, but let me make a serious point. There's performance and then there's performance. If the user can't tell the difference, why violate the "rules"?