OPTION STRICT VAR SCORE SCORE=0+(a bunch of code here) IF SCORE>99999 THEN SC0RE=99999I made a typo in "SC0RE" so OPTION STRICT will catch it, but without that (the default) SB will just treat it as another variable, and I will most likely miss it.
4) The interpreter runs faster because it's not having to constantly check if a variable is defined and define it if it's not already. It can assume the programmer will do this.I don't think this last point actually applies to SmileBasic. If there is no OPTION STRICT, I think the system will scan through the file for things that look like variable names, then virtually insert a VAR with all those identifiers, before running the file. At least, that's the way it seems to be for programs that don't muck about with other slots. For those programs, things might be much more interesting; I don't know.
There's no hoisting, but this is how I believe it works. I've heard that PTC was slow to allocate VARs and that's why programming in the manner OPTION STRICT forces you to, was so useful there. Theres no (edit: measurable) performance difference now, and the only way you'd get that is a pre-pass.4) The interpreter runs faster because it's not having to constantly check if a variable is defined and define it if it's not already. It can assume the programmer will do this.I don't think this last point actually applies to SmileBasic. If there is no OPTION STRICT, I think the system will scan through the file for things that look like variable names, then virtually insert a VAR with all those identifiers, before running the file. At least, that's the way it seems to be for programs that don't muck about with other slots. For those programs, things might be much more interesting; I don't know.
There's no hoisting when using OPTION STRICT. When not using it, implicit global declarations of all variables that don't have an explicit declaration are hoisted. PTC has no OPTION STRICT, DIM is only for arrays, and there's no VAR. SmileBasic does at least one pass of the code before beginning execution, at least with OPTION STRICT, because you can get Undefined variable errors from lines that can't possibly get executed.There's no hoisting, but this is how I believe it works. I've heard that PTC was slow to allocate VARs and that's why strict was so useful there. Theres no (edit: measurable) performance difference now, and the only way you'd get that is a pre-pass.4) The interpreter runs faster because it's not having to constantly check if a variable is defined and define it if it's not already. It can assume the programmer will do this.I don't think this last point actually applies to SmileBasic. If there is no OPTION STRICT, I think the system will scan through the file for things that look like variable names, then virtually insert a VAR with all those identifiers, before running the file. At least, that's the way it seems to be for programs that don't muck about with other slots. For those programs, things might be much more interesting; I don't know.
VAR STRING$ 'string variable VAR REAL# 'real number variable VAR INTEGER% 'integer variableHowever, when you don't specify a suffix on the end of a variable name, SB assumes the variable is a real number by default.
VAR REAL 'is real type be default VAR INTEGER%When you use OPTION DEFINT, the system assumes variables without name suffixes are integers instead.
OPTION DEFINT VAR INTEGER 'is integer type by default VAR REAL#My tip to you is this: NEVER use OPTION DEFINT and always specify the proper type suffixes on the end of names. It makes your code better and less ambiguous to people reading it.
