Nested FOR/NEXT loops with Same Variable Names

[Qwerkey]

I discovered the following in some code of mine, where I had stupidly given two nested FOR/NEXT loops the same variable name.  Fortunately (?), it did not give an error in the actual program.

Code: QB64: [Select]

1. FOR S% = 0 TO 26
2.     FOR R%% = 0 TO 7
3.         PRINT R%%;
4.         FOR R%% = 0 TO 7
5.             A = A + 1
6.         NEXT R%%
7.         B = B + 1
8.     NEXT R%%
9. NEXT S%
10. PRINT
11. PRINT A, B

I have removed many lines from my program to give the simplified nested loop above where the variable R%% is used twice in the two inner FOR/NEXT loops.

Should the IDE not have picked this up as an error?  And I rather surprised that this doesn't cause an error at execution.  You can't cater for all the stupid things which users do!!

[FellippeHeitor]

QB64 wouldn't have how to figure whether it's intended or not.

[bplus]

The duplicate R%% may not give error, why should it? But is surely throws off a normal triple loop count, see here with inner most R%% repalced with Q%% (attached) = many many more loops!

[SMcNeill]

The duplicate R%% may not give error, why should it? But is surely throws off a normal triple loop count, see here with inner most R%% repalced with Q%% (attached) = many many more loops!

It shouldn’t, as it may be intentional.  QB64 can’t know how you’re coding.

For example, let’s use a sorted array of 10,000 elements with values between 1 and 10...

Now, there’s going to be lots of duplicates, right?

What if we only need to do something once for each unique value?

FOR x = 1 TO UBOUND(array)
   PRINT array(x)
   ‘Do lots of other stuff if you want
   FOR X = X TO UBOUND(array)
      IF array(x + 1) <> array(x) THEN EXIT FOR
   NEXT
NEXT

The above increments X on purpose, so only unique values are printed and processed...  it’s not a glitch at all, and works 100% as intended.

How is the IDE supposed to know this is good and proper, while the original isn’t?

Sometimes, we just have to find and debug our mistakes ourselves.

[Cobalt]

Sometimes, we just have to find and debug our mistakes ourselves.

I think Steve nailed it there, in the end we programmers still need to be responsible for good clean code. And to that end, a little proof reading can go a long way sometimes.

[Qwerkey]

The duplicate R%% may not give error, why should it? But is surely throws off a normal triple loop count, see here with inner most R%% repalced with Q%% (attached) = many many more loops!

Likewise, I discovered that the second FOR/NEXT loop gets terminated at the first value if the third loop has the same variable.  When I "corrected" the third loop with a different variable name (with all the proper extended iterations), my actual program behaved incorrectly.  I shouldn't have had the second loop in the program at all!  Utter stupidity!  It's a good thing that QB64.org doesn't have a threshold for User Capability.

[Cobalt]

It's a good thing that QB64.org doesn't have a threshold for User Capability.

Be a very empty place if there were!

I'm constantly finding code that makes me stop and say to myself 'what the hey was I thinking!'.

[TempodiBasic]

Hey
Often reading again my code written just some times before, I think "But what the hell  have I written in this way?"
:-)

[STxAxTIC]

I fear the opposite - that my previous self will be more clever than my future self. Classic case in point: forgetting a password.