>Nope, jump right in.
>
>The FOR ENDFOR construct is used when the number of iterations is known in advance. DO WHILE is used when there is a conditional test. Even if one is faster than the other, you cannot always apply both, so your example isn't a straightforward comparison. This is a good example of what I'm talking about. We should know which commands to use and when. If the the number of iterations is known, would you write DO WHILE lnI < nIterations? Of course not. But, how can a novice learn not to do that?

I think that in essence we agree. I would, however, expand on or modify your statement to say that the number of iterations are fixed. Unless there are overriding considerations, such as an extremely high number of iterations (such as 100,000 or more), if the termination of the loop should occur based on either the maximum number is reach or some logical condition, then a DO WHILE cibstruct is required. Unfortunately, even Microsoft's documentation fails to follow this. For example, here's a case from Chapter 17 of the Programmer's Guide:

lModified = .F.
FOR nFieldNum = 1 TO FCOUNT()         
   IF GETFLDSTATE(nFieldNum) = 2      
      lModified = .T.
      EXIT
   ENDIF
ENDFOR

We know that FCOUNT() will not return a value greater than 255, so the number of iterations here will not be a factor. So a DO WHILE structure is indicated. I should note that it is possible to construct this without a loop (lModified = (REPLICATE('1', FCOUNT() + 1) = GETFLDSTATE(-1))). This takes into account not only if the record has been modified, but if it has been marked for deletion as well, which the above code does not.

How can you teach a novice this? I'd say that the key to it is in defining the purpose of the constructs. This not only applies to the individual programming structures and commands, but for the purpose of design of the code as well. The more strictly the purpose of a module is defined, more likely it is to exhibit high functional cohesion. This, of course, is a highly desirable trait (along with loose coupling). In the case of FOR...ENDFOR versus DO WHILE...ENDDO, we can define the former as being used in those cases where the number of iterations is fixed. The latter when it is 0 or more and the number of total iterations is dictated by a logical condition.

It's my personal opinion that one of the most oft times recurring "mistakes" (they're not really errors, but rather poor practices) is in the handling of Boolean conditions. I can't tell you how many times I've seen statements such as IF llogical = .T. rather than simply IF llogical (this again appears in the VFP documentation). Another one is in the assignment of a logical value, such as:

If lsomevar >= lsomeother
  lmyvar = .T.
ESLE
  lnmyvar = .F.
ENDIF

Rather than the more straightforward (and, yes, faster< g >)

lmyvar = (lsomevar >= lsomeother)

.

I think we're on the same page here, just expressing it in different ways.:-)