Program Flow vs Coding Order

[Pete]

I started this thread for us to post some snippets that illustrate how coding order trumps program flow in expected results.

Steve brought up a good example in regard to sub sorting from : https://qb64phoenix.com/forum/showthread...1#pid39631

Code: (Select All)

INT: FOO 

 

SUB INT

    DEFINT A-Z

END SUB



SUB FOO

   PRINT LEN(x)

END SUB 

Now switch that to...

Code: (Select All)

INT: FOO 



SUB FOO

   PRINT LEN(x)

END SUB



SUB INT

    DEFINT A-Z

END SUB 

Changing the program flow won't change the outcome. Call FOO: INT or INT: FOO and the results will be the same. It' the flipping of the SUB codes that influence the outcome. The coding order in the first example treats x as an integer, because the sub containing DEFINT was placed before the sub containing the Print statement. The results of Len(x) will be 2 bytes. Switch the subs in the code and x remains an undeclared default single, (so Len(x) will be 4 bytes) even if you call INT first.

Now here's one that nailed me decades ago, my first encounter with "Duplicate Definition".

Code: (Select All)

GoSub pete

Print MyArray(1)

End



pete:

ReDim MyArray(10)

MyArray(1) = 5

Return

So again the program flow seems like it should handle the situation, as the Gosub statement leads us to the Redim of the array, before we print the array value. Ah, but the coding order shows that from top down, we tried to print the value before we dimensioned the array. So the fix is simple, just remember to...

Code: (Select All)

ReDim MyArray(0) ' We'll increase this value in the Gosub.

GoSub pete

Print MyArray(1)

End



pete:

ReDim MyArray(10)

MyArray(1) = 5

Return

So please share other examples where coding order effects outcome, regardless of program flow, in this thread.

Pete