Not declaring Local Variables and script works ! why declaring them then ?

[teriibi]

Hi,

I read that global variables have their Pro and cons..

What about NOT declaring a local variable,
I can see that LC still handles very well my script when I skip declaring some local variables...

Can someone give sample where when NOT declaring a local variable you get wrong results or errors.. ?

(...or, why bother in declaring those local V. since it works even without this step ?)

[Klaus]

Hola teriibi,

when in the script editor, check menu "Edit", if the last entry "Variable checking" is checked, then you MUST declare local variables or you will get a compilation error. If not checked, no declaring neccessary.

You have to decide for yourself, if you really need this.


Best

Klaus

[bogs]

What about NOT declaring a local variable,
I can see that LC still handles very well my script when I skip declaring some local variables...

Can someone give sample where when NOT declaring a local variable you get wrong results or errors.. ?

Well, IF I read your question right, I think I can give you an explanation. The question really is what you mean by 'local variable'.

In Lc, where you can create variables on the fly, here is where not creating an actual local variable could get you into trouble. In this demo, I created a stack and a button, all the code goes in the main stack.

1.) no declared local variable - in this case, since the variable is undeclared anywhere other than each handler, it is created 'on the fly' and will have whatever information is inside as a result of your handler. It will not be the same answer in another handler necessarily, so if you are looking for a particular answer, you will not get it.

Code: Select all

on mouseEnter
   if word 1 of the target is "button" then answer tmpUndeclaredVar       
end mouseEnter

on mouseUp
   put the short name of me into tmpUndeclaredVar
   answer tmpUndeclaredVar
end mouseUp

2.) declared local variable - In this case, you have to click somewhere inside of the form to fill the variable, but you will see once filled, it is the same variable in each handler.

Code: Select all

local tmpDeclaredVar // local variable

on mouseEnter
   if word 1 of the target is "button" then answer tmpDeclaredVar       
end mouseEnter

on mouseUp
   put the short name of me into tmpDeclaredVar
   answer tmpDeclaredVar
end mouseUp

Now, if you meant something else, I didn't get it.

[dunbarx]

What Bogs has really spoken about is a "script local" variable, that is, a local variable that will retain its value over an entire script. I am sure you know that a script may contain many handlers, and it is among ALL the handlers in a script that such a variable will be accessible.

Note that the declaration MUST be made ABOVE any handlers that may need the variable. It is not common practice, but it is possible (and useful for your understanding) that in the following construct:

Code: Select all

handlerA
handlerB

local tVariable

handlerC
handlerD

tVariable will only be available between "C" and "D". Anyway, in general, declarations are made at the top of the script. That covers all bases, and you know where to look for them later on.

Craig Newman

[teriibi]

Yes Graig - I was refering to a local variabe such as: ttime, declared above...

Code: Select all

local ttime
on mouseup
put empty into ttime.
put "5 Pm" into ttime
end mouseup

tks bogs, I tested both script but couldnt nothe a behavior diference. ..guess I need more coffee
Hi Klaus. yeah so its almost a matter of own coder pref. -
I actually love that LC allows it to be on the fly and that the creators founda way to handle local variable this way !

...therefore should I worry too much or not really ?
(but in some rare case for not having delared locals)

[bogs]

Thank you Craig, that was a good point, and summed up a lot better than I did.

tks bogs, I tested both script but couldnt nothe a behavior diference. ..guess I need more coffee

No problems, the example was pretty poorly constructed, but I'll show you the difference between the two. First, an explanation of why I set it up with two handlers.

If you had all the statements in a single handler, a variable created on the fly would work, because the variable is within the handler. In the first example of code, the variable tmpUndeclaredVar is actually 2 separate variables, despite being named the same. Now for what you (should) have seen -

No local variable (above the script) - on the mouse entering the button, you should see nothing more than an answer dialog with 'tmpUndeclaredVar' , the name of the variable created on the fly. The reason you see that is because we didn't put anything into 'tmpUndeclaredVar' in that handler, and because it is in that handler, nothing out side of that handler is ever going to put anything into it.

Mouse entering the button...

The second handler, mouseUp, *does* put something into the 'tmpUndeclaredVar' within this handler, in this case when you click on the card, it puts the short name of the stack into 'tmpUndeclaredVar', and then pops up the answer dialog with that shown.

Mouse click on the card...

Selection_005.png (18.79 KiB) Viewed 8031 times

To prove to yourself that both of these variables are completely separate, regardless of the name being the same, you can now have the mouse enter the button again, and you will see the first picture with the answer being 'tmpUndeclaredVar'. We know that the tmpUndeclaredVar in the mouseUp handler has a value, but the mouseEnter handler will never see this.

As a result, if you were expecting such a variable to have a certain value, your program will not be able to put it into effect if called from a separate handler.

Local variable (above the script) - Now you'll see if you click on the card after declaring "local tmpDeclaredVar" (and changing the names in the mouseEnter / mouseUp handlers) that the variable really is available over all the handlers that follow it, as Craig pointed out.

Click on card fills the variable...

Selection_006.png (11.02 KiB) Viewed 8031 times

If you mouseEnter the button now, you will see the same answer, the short name of the stack.

As Craig also pointed out, you can change the behavior quite a bit of a 'local variable', depending on where you put it. My tendency when programming is to declare all variables right at the top, and I keep a running list of those in a text program since it usually only requires a few lines.

For most things, you are not going to require massive amounts of variables, so using unique ones isn't a vast strain.

[bogs]

when in the script editor, check menu "Edit", if the last entry "Variable checking" is checked, then you MUST declare local variables or you will get a compilation error. If not checked, no declaring neccessary.

You have to decide for yourself, if you really need this.

I should also point out that what Klaus said about the variable checker can save you a lot of headaches, as it will catch if you mistype a variable name by popping the 'undeclared' warning at you.

Also you ultimately need to know the scope your expecting from the variable to determine whether you need to make it local, global, or on the fly. Basic rules of thumb -

1. on the fly - if it is only in one handler, or you want to use the same var name multiple times in many handlers but it doesn't have to have a value other than what the handler it is in is doing
2. script local - more than one handler will be expecting the previous handler that uses this var to have put information into it within the same script.
3. global - works from anywhere in the program, but you need to be more careful with it, often setting a custom property works better.

These are just my take on it, lots of opinions in this realm

[jacque]

Script local variables have been described. Variables used only in a single handler do not need to be declared. There are two main reasons why you might want to declare them in a handler:

• When explicit variable checking is turned on, typos or undeclared variables will produce a script error. This prevents you from making mistakes that could cause problems later.

• If you plan to distribute your work to other developers, they will get dozens of errors if they have explicit variables turned on. For this reason all shared stacks for the public should declare variables inside handlers.

If you never use variable checking and you are the only person developing the stack, you don't need to declare handler variables. I almost never do.

[[-hh]]

There is moreover one important feature of local variables.
They are comfortable in that they can have a default value, so no check for empty is needed after startup.
For example

Code: Select all

local mySwitch=true, myName="donald", myNumber=42

[mwieder]

Jacque and I have had this running argu^H^H^Hdiscussion for years now.

I *always* declare my variables. Yes, even within functions, and I have 'strict variable checking' enabled to catch me if I forget one. I believe in letting the compiler do what it was designed to do instead of doing the work manually of making sure I haven't mistyped a variable name or tried to use a variable I haven't initialized yet. I find the extra keystrokes of declaring a variable (and it becomes second nature quickly) is more than offset by having the compiler find problems for me early in the game.

[bogs]

I'm kind of in-between both sides, I don't have strict checking on, but out of habit I tend to declare all variables (unless during testing I need an extra one on the quick, then I create it on the fly). If it stays through testing, I go back and add it to the list.

Just part of the whacky happy weird world of programming I guess

[jacque]

Jacque and I have had this running argu^H^H^Hdiscussion for years now.

I *always* declare my variables. Yes, even within functions, and I have 'strict variable checking' enabled to catch me if I forget one. I believe in letting the compiler do what it was designed to do instead of doing the work manually of making sure I haven't mistyped a variable name or tried to use a variable I haven't initialized yet.

That's because I'm a better typist than you. I don't have to.

[bogs]

FLAME ON!!

FLAMETHROWER.GIF (17.72 KiB) Viewed 7852 times

[mwieder]

I don't have to.

You misspelled "two".