>>< BG >I guess so. On the serious side, when we call a function that returns a Boolean value it's usually in the hope that it'll succeed.
>>
>
>Would you say that has alot to do with your rule #3 - No premature exits?

No, #3 is more geared to using the right iteration structure for the job. As I'm sure everyone knows, there are three: Pre-test, Post-test, and Fixed. Unfortunately, VFP doesn't have a native Post-test, we have to simulated it forcing a DO WHILE to iterate one time.

Before we take this thread into a "Well, but FOR...ENDFOR is faster" direction, I should point out that sometime ago, Bruce Campbell and I had this discussion. The outcome was that you have to literally get into the thousands of iterations before a difference of as much as a tenth of a second is realized.

In this vein, I should note that the rules are not absolute. If there is a quantifiable reason for breaking them, then I break them. However, such reasons are, in my case, few and far between. I can give an example, however, of a case where there was a reason (I've got to go back to FPW to do it, however).

As many of us recall, in FPW you have an option to let the screen generator create code to open and close the necessary tables. I abandoned using the option after a few experiences with it. I called a function to open the tables, and a procedure to close them. If the function failed, because of the way the code was generated, there was no way to by-pass the screen definition and exit, unless you did a return in the setup code. If you didn't bypass the screen code, errors would abound. So the only way to solve the problem was to issue a RETURN in setup if the function failed. A quantifiable reason.