>This line of code brings up a topic that has always bugged me....
>
>
>IMHO, placing returns in the middle of code blocks can make for a lot of problems. Rather, I would suggest:
>
>
>I wonder what other's think?????
>

I try to follow the "one exit" rule but find the one place I seem to violate it is in "initial state" checking and/or parameter checking. I think part of the reason is that I hate ending up with monster IF/ENDIF statements (in code segments where there is a lot going on) with my exit to the error condition way at the bottom. I've found it's easier for me to understand the code if I simply exit at that point instead of having to have that extra ENDIF (or whatever) statement at the bottom that I need to remember.

--------------------------

* Check passed in parameters to make sure
* everything looks OK.

IF
* Something bad happened, exit
RETURN -1
ENDIF

* At this point I know my data should be good and can continue processing

RETURN
--------------------------

But, there are still a lot of good arguments to be made against doing it at all. I differ a bit from Ken in that in "simple" functions or procedures I'll use the format:

LOCAL llReturn

llReturn = .F.

IF
* Do something
llReturn = .T.
ELSE
* Don't do much (display/log error, etc)
ENDIF

RETURN llReturn