LoginLogin

Local/Global Variables

Root / Submissions / [.]

12Me21Created:
You might have had this problem before: 
FOR I=0 TO 3
 TEST
NEXT

DEF TEST
 FOR I=0 TO 7
  PRINT "A";
 NEXT
END
The FOR I=0 TO 3 code only runs once, since I becomes 8 after TEST is called. The way to avoid this is by using local variables. These are special variables in functions that won't affect global variables (variables outside of functions) with the same name. To use local variables inside functions, VAR* them within the function: 
X=2 'global

DEF TEST
 VAR X=4 'doesn't affect the global variable "X"
END
If you want to access global variables, you must use the variable outside the function first (be sure to VAR your global variables before any DEFs) Right: 
VAR X=2

DEF TEST
 X=3
END
Wrong: 
DEF TEST
 X=3 'accesses the local variable since the global one hasn't been used yet
END

VAR X=2
*VAR and DIM are exactly the same; most people use VAR for regular variables and DIM for arrays.
more examples 
DEF TEST1
 A=7 'local (don't do this, use VAR)
END

A=3 'global

DEF TEST2
 A=7 'global
END

DEF TEST3
 VAR A=7 'local
END

DEF TEST4 A
 A=7 'local
END
DEF TEST5 OUT A
 A=7 'local
END
original incorrect informationLocal variables in SB are pretty weird Whether a variable in a function is local depends on whether the variable was used outside the function before (on a earlier line) 1: VAR/DIM doesn't actually do anything (VAR I=1 is equivalent to I=1). OPTION STRICT will not change this, it just causes an error if you don't use VAR the first time 2: There can be different variables with the same name (one global version, and multiple local versions (inside functions))
example
DEF TEST
 A=2 'local
END

DEF TEST2
 PRINT A 'different local variable
END

A=7 'global

TEST 'only sets its own copy of the variable (does nothing)
TEST2 'prints 0
3: During pre-compilation, SB reads the code from top to bottom to look for variables
example
OPTION STRICT
GOTO @SKIP
 VAR X 'SB sees this even though it never gets run. (This only affects OPTION STRICT)
@SKIP
X=1 'does not cause an error
4: Variables defined inside of functions are normally local
examplesee example 2
5: Variables outside of functions are always global
example
DEF TEST
 A=7 'local variable
END

A=3 'global
TEST 'only sets its own local variable "A" 
PRINT A 'prints 3
5: Once a global variable has been defined, all variables after it with that name will be global (including inside DEFs)
example
DEF TEST1
PRINT A 'local
END

A=4 'global

DEF TEST2
 PRINT A '<-global!
END

'What matters is the order of the DEFs, not the order that functions are run!
TEST2 'prints 4
TEST1 'prints 0
(and in case you're wondering, function arguments and OUT returns are always local) (also, different slots use completely separate variables, so don't worry about that)
ResourcesAdvanced Tutorials
MZ952#1
This is very useful to know! So, if I keep all my DEF functions at the top of the program, I can avoid having the functions' variables affecting outside variables? I wonder why not just keep all variables inside DEF functions local, or why not let the programmer specify it with a command like COMMON.
kldck_hul#2
So I noticed that your points 1 and 2 are incorrect... The code below will use only one variable: 
VAR A=7 'global

DEF TEST
 A=2 'not local
END

DEF TEST2
 PRINT A 'the same global
END

TEST 'sets the global
TEST2 'prints 2
This has to do with where the statement defining the global is placed. The commands in your example are defined before the global, and as such, don't know that A is a global they can assign to. It hasn't been declared yet.
kldck_hul#3
Replying to:MZ952
This is very useful to know! So, if I keep all my DEF functions at the top of the program, I can avoid having the functions' variables affecting outside variables? I wonder why not just keep all variables inside DEF functions local, or why not let the programmer specify it with a command like COMMON.
Its very easy to keep your local and global variables from mixing, even if they come after those global variables. You just have to redeclare the variable in the DEF block using VAR. I recommend ALWAYS using VAR the first time a variable is seen. Using VAR does do something, and I believe 12Me21 made an honest mistake and missed it. Take this code as an example: 
DEF TEST
  INC iter%
  'Hasn't been declared as global yet
  'will create a local 
  PRINT "1:",iter%
END

VAR iter% = 42
 'Declare iter% as a global

DEF TEST2
  INC iter%
  'Will increment the global variable
  'because it was declared prior
  PRINT "2:",iter%
END

DEF TEST3
  VAR iter% 'Shadow the global
  INC iter%
  'Will increment the local
  'because it is declared inside
  PRINT "3:",iter%
END

DEF TEST4
  INC iter%
  'Has been declared as global
  PRINT "4:",iter%
END

TEST;TEST2;TEST3;TEST4
Edit: more complete example
12Me21#4
Replying to:MZ952
This is very useful to know! So, if I keep all my DEF functions at the top of the program, I can avoid having the functions' variables affecting outside variables? I wonder why not just keep all variables inside DEF functions local, or why not let the programmer specify it with a command like COMMON.
oh thanks! I really should have known this; it seems so obvious now. Well, at least I have the perfect idea of how to reuse this page.