LoginLogin
Might make SBS readonly: thread

Option Strict is Good

Root / Submissions / [.]

randoCreated:
There have been many lazy people, who think that declaring variables sucks and makes everything harder; even though it does suck, it also doesn't. Here OPTION STRICT will be explained. The people shall not be lazy, by being lazy. The whole world will rejoice because of OPTION STRICT, the command lazy people hate. Now, everyone uses variables. They store data and make games playable. This is not a variable tutorial, so anyone wondering about those go through randomouse's tutorials. Anyway, with variables, anyone can make bad to ok software. But not everyone is perfect. Everyone who types makes errors in typing. Most don't notice their error, so it doesn't get fixed. Now, this can get messy, especially with variables. When a variable is created, it defaults the variable as 0, unless it's a string, in which case it is just "", or empty. So, when a variable is declared, it needs to be set, or it can be set later with the = sign. But when you make a typo, you might have set VARIABLE% and accidentally used VARI%. It doesn't recognize this variable. Now, if OPTION STRICT isn't used, it'll just make a new variable. This variable is gonna be 0, because the program just made a new integer. If VARIABLE% had previously been set as 5, there would be a problem where VARI% was used. If this was in your code:
?"A"*VARI%
there would be a problem. It should have put
AAAAA
assuming VARIABLE% was set to 5. But VARI% was put. This is where OPTION STRICT helps. In bigger programs, it can be hard to find these errors. This is because SmileBASIC doesn't tell the user that something is wrong. SmileBASIC doesn't know something is wrong. So when you use OPTION STRICT, SmileBASIC gives an error and the user can go back to fix it really fast. OPTION STRICT tells the user about the variable that doesn't exist, so that it can be fixed.

Not useful at all, although, it needs more code and a more explicit structure in order to make it work.

Replying to:the_squat1115
Not useful at all, although, it needs more code and a more explicit structure in order to make it work.
wut also I now know the real stuff behind option strict like in really big programs and making typos lol

Replying to:the_squat1115
Not useful at all, although, it needs more code and a more explicit structure in order to make it work.
if you type in a variable name wrong your program just refuses to run instead of maybe working until a certain point, which saves you effort trying to debug it. I dont know how this isn't useful

Replying to:the_squat1115
Not useful at all, although, it needs more code and a more explicit structure in order to make it work.
For programs with a few (global) variables this makes little sense to use - as long as you realy, realy, realy, realy know what you are doing. (For example: combine several small programs into one larger one ; but in this case it is still usefull for debugging.)

Why the downvotes? This is a good guide.

Replying to:the_squat1115
Not useful at all, although, it needs more code and a more explicit structure in order to make it work.
yes

Replying to:HTV04
Why the downvotes? This is a good guide.
well, not exactly. It does help a bit with user defined instructions, but not with the rest of option strict. Now I should edit this now that I know the real purpose of option strict lol

Replying to:HTV04
Why the downvotes? This is a good guide.
And I'm even the one who made it lol

Replying to:HTV04
Why the downvotes? This is a good guide.
Well the premise is sound and correct. Everyone should be using OPTION STRICT for everything but the most throw away tiny bits of code. Unfortunately the argument to use it is somewhat lacking. Sentences like this "Basically you make your own lines of code by using other codes to do things ..." also make it sound like the author doesn't actually know what they are talking about (even though their conclusion is correct). The author isn't making a persuasive argument and doesn't seem to be an authority on the subject. I think that is the source of the down votes. Or it could just be sour little kids angry they are being told to do things the right way. As an aside, you want to use functions and local variables. (The author is correct about this as well.) In fact you should minimize global variables and put as much as possible in variables local to a function or subroutine. This helps to make your code much cleaner, easier to read, re-purpose, and test. Putting everything at the global level makes spaghetti code which is terrible to try to update, fix, edit, or understand. However, this doesn't really have anything to do with OPTION STRICT. If you don't use OPTION STRICT, when the interpreter finds a variable that it hasn't encountered before it decides that you know what you are doing and just declares it for you. That sounds nice, right? On a certain level it is. However, there are things that people are good at and bad at, and likewise things that computers are good at and bad at. So while it declaring variables for us might be pleasant, we can actually make the computer do something much better and far more useful. Have you ever made a type-o, or misspelling? I sure do. I would be surprised to write 100 lines of code and not have made at least one. If you let the interpreter just declare variables for you on the fly you can introduce semantic errors. Errors in your code that come from bad logic instead of bad syntax. By default a new variable is initialized to an empty string or a zero (depending on if it ends with $). So, if you meant to type MAP_WIDTH and instead type MAP_W you suddenly have a map that is zero tiles wide.These sorts of problems can be overlooked and missed entirely, or cause all sorts of hard to track down and fix errors. However, if you use OPTION STRICT, you are required to declare all of your variables ahead of time. Now the interpreter can say I found a problem on line x column y when it is parsing through your code before anything ever runs. It converted a semantic error into a syntax error. An error located at a exact spot in the code. Syntax errors are easy to fix, semantic errors are much harder. So trading a semantic error for a syntax error is a huge benefit. Furthermore, you get the peace of mind that you don't have an rogue variables in your code once it does parse successfully. Something you don't get if you don't use OPTION STRICT. This is a very powerful tool that you would be wise to make use of. If you do intend to pursue a potential career in programming, you may as well get used to declaring your variables ahead of time and giving them types. Pretty much any C-style language will make you do it. Ones that don't will be the exception, not the rule.

Replying to:HTV04
Why the downvotes? This is a good guide.
yeah lol you should have written this xD Time to press the EDIT button

Replying to:HTV04
Why the downvotes? This is a good guide.
k made it good and accurate and formal and stuff

Replying to:HTV04
Why the downvotes? This is a good guide.
Finally someone makes a guide for it, OPTION STRICT is such a more tedious but more useful tool while reading this.