OPTIONs

OPTION DEFINT according to the manual means that variable will be defined as intergers. That the same deal as default (as far as I know). When and where is OPTION STRICT useful?

I'm pretty sure the default is floating type, so setting OPTION DEFINT will make all variables integers and thus increase performance. OPTION STRICT demands the user to define all variables using VAR (otherwise it'll spit out an "undefined variable" error). I've seen a lot of games using this. Apparently the developers find it useful in that it prevents accidental typos. Example

OPTION STRICT
VAR SCORE
SCORE=0+(a bunch of code here)
IF SCORE>99999 THEN SC0RE=99999

I 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.

Makes sense.

What lohadl said is correct :) by the way, JavaScript has the same thing. If you put "use strict"; at the top of a JavaScript file, it will require variables to be declared, just like OPTION STRICT in SmileBASIC! There's also some other things that it causes errors with. http://www.w3schools.com/js/js_strict.asp It turns pull-your-hair-out bugs into simple things!

Thanks,one question though. Why do I receive an error when I input bu=BUTTON(2)

I used variables and receive no errors but with that single line of code I receive error, I have no goto loop

If a variable is declared without a suffix in SB, it will naturally assume the "real" type. OPTION DEFINT means that a variable declared without a suffix will naturally assume the "integer" type; however, you can still declare reals by using the # suffix. I use OPTION STRICT because of four main reasons: 1) Typos in a variable name will be caught instead of being defined as a new variable. 2) It forces some level of order into your code. 3) Variable declaration is required in a lot of major languages (like C#), so it feels more natural for variable declaration to be required. 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.

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.

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, 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.

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.

PTC has no OPTION STRICT, DIM is only for arrays, and there's no VAR.

Yes. Sorry. I meant the same practice. Defining all your variables at the top of the file (there weren't scopes right?).

I don't think we were sufficiently clear on DEFINT and variable typing so I'll be a bit more thorough. SB, unlike PTC, has two different number types: integers and real numbers. These types have suffixes like strings do.

VAR STRING$ 'string variable
VAR REAL# 'real number variable
VAR INTEGER% 'integer variable

However, 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.

Oh OK

Is there any advantage of using integers (other than know that your code is more efficient)? are they faster or anything? I just hate typing % everywhere