Absolute need of goto 4 correct functioning of loop routine.

[na_th_an]

Meg, you are still losing my point: optimization. GOTO may be faster. It depends on the kind of coding you are doing.

It looks like I use 20,000 gotos per program, but in fact you can't hardly see more than 1 or 2 per 3,000 lines of code.

It's just that: when you need speed, you can lose a lil' bit of readability.

Plus, seriously, I just didn't know that EXIT FOR exitted all the nested FORs. I thought that it just exited one.

I expect the loop to run 10 times, and for i% to equal 11 when it's done. If you're kicking out of the structure before this exit condition is met--either via GOTO, EXIT, etc--maybe you shouldn't be using a FOR...NEXT loop in the first place. Personally, I like to see the exit condition of a loop met to make it stop running, if at all possible.

Exactly what I posted in the other post. The correct construction, if you need to exit a FOR loop, is to make a DO:LOOP or a WHILE:WEND with a correct exit condition. My point back there was that breaking from an apparently "closed" structure (a FOR:NEXT is supposed to loop a fixed number of times) with a GOTO or with an EXIT FOR is just the same: bad. The EXIT FOR/WHILE/DO/FUNCTION/SUB/FN stuff is there 'cause some funky thinker in the microsoft team. My point is that breaking from a for loop, sub, function, while... etc is "bad practice" by itself, exactly as bad as using GOTO. Notice that the EXIT blah stuff looks cleaner, but in fact it's the same: you are suddenly breaking from a loop. That's why I didn't understand why you defended EXIT and dismissed GOTO. If you tell me "it's just for cosmetic coding" I have to agree, but logically it's the same.

Why do you want to exit suddenly from inside a loop? for speed. Can it be overcame using structural programming? of course. Is it always slower? not at all, sometimes it will be slower, sometimes it won't. But it may look less readable at times.

For example, you can avoid EXIT FUNCTION using IFs intelligently in your FUNCTION. But it may look bloated. Sometimes placing an EXIT FUNCTION may help you having less code. Sometimes it will look better, sometimes it won't. See what I mean? Readability and cosmetic coding is awesome when you are teaching someone, and I already stated that I'm with you when it comes to show newbies how to code, and that I understand that you may feel with some kind of "responsability" over them, 'cause I've also felt that way sometimes that people have suggested to use GOSUB, inter-module globals or something like that. But when you are coding for yourself, a little bit of dirty optimization can gain you a few more fps

Also, what you say about calling SUBs to isolate logics looks good and organized, but everytime you call a SUB you waste time and memory.

Which such kind of optimization we made our last project from college process a sound signal with a simulated ADSP21 microprocessor take half of the time it took without it. The simolator core is horrid, absolutely ugly, but when you need speed you notice that unrolling loops or replicating code works.

What I mean is that many times we say "GOTO is bad" without stopping a little to think that many of the "alternative features" of QB are as bad... or as good.