>>
>>Both Loop and Exit were there since at least 1989, in FoxPlus.
>>
>Jeez! then I've been getting along quite nicely without them for longer than I thought!!

And you weren't even aware how happy you lived all the time...

>No, people got on OK pre-1989. I wasn't saying they're as recent as mobiles (anyway - the offending code I was looking at dates from 1992!)

The offending code may need general refactoring, if it's so old. I figure the author used the tecniques known at the time and probably painted himself (ahem, themselves?) in the corner where Loop/Exit seemed simpler than alternatives.

At that time (1989) I got introduced to Fox, and there were a few things that I hated - namely, that you could (had to!) use strings without quotation marks in a bunch of places, like in use command, and that it didn't have a Repeat/Until loop. However, Loop and Exit weren't on my list of complaints; I used them whenever I needed to, though as time went by, they have gradually vanished from my code.

>>If I see a for/next loop going through an array to find something that can't be found by simple aScan(), I know I'll be looking for

if (some condition)
   cVar=(something taken from the array)
   exit
endif

>>
>>There's no way you can force me to go to the end of the loop. Even if this sort of for/next loop was simulated with a do/enddo loop, it would introduce an extra exit variable, plus the code to increment the index variable, which would be even more clumsy.
>
>Funny - I've been often tempted to do that but i guess I do it the "clumsy" way, to keep to my principles.

If your principle turns a four-liner into a dozen-liner, I'd probably not feel tempted to fix it if it was in some code I'd have to work over, but I'd surely frown.

>>The other place where I may use either of Loop or Exit is a heavy and slow process which involves a scan/endscan, with a do/don't condition being too difficult to express in terms of Scan For (condition). There:

scan
   bla bla bla... more heavy checking... bla bla
   if not <some condition>
* we don't do anything with this one
      loop
   endif
* now the meat of the process
endscan

>>
>
>How about:

scan
   bla bla bla... more heavy checking... bla bla
   if < some condition >
       the meat of the process
   endif
endscan

That's what I usually do. The emphasis here was on heavy, when the conditions are numerous and would lead to a long sausage of nested IFs, and when the meat of the process is... well, full of tendons and bones, i.e. when the extra level of indentation (even with my tabs set to 3) would just make it hard to follow.

Come to think of it, I'm not writing such code myself. It's in inherited code I got from others, where I'm happy to leave early bailouts as they are, and where I don't even suggest to rework it. You see, I've already seen what it does, and I know how it works, and I know that it works. So I don't see a reason to change it, not in that part.

I've just checked the last project I worked on. I got three Loop commands: one is in the Otherwise clause of a case statement within a scan loop which has to find six records with certain properties; so it does a Loop if the current record is unusable. It also has an Exit if we're past six records. The conditions here are that there may be between zero and n records to check.

Second one, counting records in table B with a given key, while in a scan/endscan on table A. If count is greater than 6, loop. Since the loop is quite short, about 10 lines to the endscan, I concede this really could have been if _tally<=6... endif.

Third one is where a lot of HTML is generated, and I have the records sorted, but need to generate text only for first ten for each group - so after 10 records, I Loop until the next group. The Loop is at the top of the loop. I'm usually doing this by "scan next 10 for{condition} " followed by "count while {same condition}". This one was maybe unnecessary, but it'd be two lines either way.

Looking for examples of Exit, I've found them far more numerous in my code, and while some really have no good reason to be there (except that they saved me coding time in routines that need to run only once), some could be avoided only by adding an unnecessary level of complexity. Example: I have a MRU list class - nothing fancy, just a container, commandbutton with a downarrow on it, and a listbox which is invisible most of the time. Now when it instantiates, it needs to read its content from an .ini file (could have been a memo somewhere, but I've found .ini files to be nice for this). During the previous run, it may have saved m out of n available entries. So it reads values Row1, Row2, Row3... until it encounters an empty (i.e. absent) one, for no more than n rows. Code follows:

For i=1 to Alen(this.alist,1)
	lcValue=prof_r(This.cSection,"row"+Transform(i),"","C")
	If Empty(lcValue)
		Exit
	Else
		this.alist(i)=lcValue
	EndIf
EndFor

The Prof_r function reads profile string. Now how would you do this one without making it less simple?