Global vars ?

[gmarco]

That's the lazy solution, but really you should just make sure you're not leaking any globals. Anywhere you define a variable, stick a "local" in front of it. If you need it accessible in a higher scope, define it in that higher scope with no value (just "local myVariable") and then give it its value later, but as a general rule, keep variables in the narrowest scope necessary. If it only needs to exist inside a certain function, make sure it's defined as local inside that function. If it only needs to exist inside a certain for loop, keep it inside the loop, etc. You can use WowGlobalFinder to help you find all the leaks in your code.

Thanks for the reply Phanx,
I opened this new post because I like to discuss about this a little bit more if possible....

Is there a reason to use a variable as NON LOCAL ?

For example ... another addon of mine: Aggromon uses some saved variables for the configuration option.
These are defined in the .toc file:

## SavedVariables: AGGROMON_ACTIVE, AGGROMON_SOUND, AGGROMON_CHAT, AGGROMON_SHOW, AGGROMON_SNDFLE, AGGROMON_ENAPVP

and in the addon I have:

local ADDON = ...
 
-- defaults if not founds values
AGGROMON_ACTIVE = AGGROMON_ACTIVE or true
AGGROMON_SOUND = AGGROMON_SOUND or true
AGGROMON_CHAT = AGGROMON_CHAT or false
AGGROMON_SHOW = AGGROMON_SHOW or false
AGGROMON_SNDFLE = AGGROMON_SNDFLE or 1
AGGROMON_ENAPVP = AGGROMON_ENAPVP or false
 
-- etc etc ...

I used them as non local, but the names should be fine to not break any others things in the UI.

The question is :-)
Is it fine or I should define them as local even if I am exporting outside the addon ...

Thanks again to all of you.

P.s
Checking better I have also this one :-)

SLASH_AGGROMON1 = "/aggromon";
SlashCmdList["AGGROMON"] = function() 
    InterfaceOptionsFrame_OpenToCategory(options)
end