[Vicster0]

Originally Posted by NonameFTW Give me some examples and I'll add in the first post. I'm currently making a Summary of all topics and their current Status.

--[[
    Example of and addon creating a table and storing all gobals in the object. 
    In this case, only the global AddonObject is exposed and all variables inside 
    are accessible via this global variable.
 
    It is also good to point out here that the values in this table can be as generically .
    named as the developer wants because they themselves are not global but rather
    exposed via a global object.
--]]
 
uniqueAddonObject = {}
uniqueAddonObject.Settings = {}
uniqueAddonObject.Data = {}
uniqueAddonObject.someNilValue = nil
uniqueAddonObject.someSetValue = 9999
uniqueAddonObject.someSetString = "I'm a string."
uniqueAddonObject.someReference = ZO_PlayerInventory
 
--[[ 
    Another way to do this is to globally expose all your globals...
    Each variable itself is globally exposed individually.
    In this case, you will want to use unique names and avoid using generically named variables.
    You can accomplish this by prefixing your 'AddonName_' to the variable for instance. There are many
    ways to do this though.
 
    Note: Developers tend to declare global constants in full caps, for instance:
    UNQIUE_ADDON_NAME_VALUE = 10
    This is obviously not necessary but can help you immediately determine if it is a global, global constant,
    or local.
--]]
 
uniqueAddonName_Settings = {}
uniqueAddonName_Data = {}
uniqueAddonName_someNilValue = nil
uniqueAddonName_someSetValue = 9999
uniqueAddonName_someSetString = "I'm a string."
uniqueAddonName_someReference = ZO_PlayerInventory
 
 
--[[
    What you want to avoid doing is making globals that are poorly named or in a scope they do
    not necessarily need to be a part of.
    
    In this case, mySettings is ENTIRELY too broad and can easily conflict with another addon or 
    the default UI. Of course, it does usually take two knuckleheads for this to be a problem. But it
    can quickly become a big problem!
--]]
 
mySettings = {}
myData = {}
mysomeNilValue = nil
mysomeSetValue = 9999
mysomeSetString = "I'm a string."
mysomeReference = ZO_PlayerInventory
 
--[[
    As I said before, it is good to keep in mind the scope of your variables/functions. There is a difference
    between globals and locals.
--]]
 
uniqueAddonGlobalObject = {}  --Global to entire API; other addons can reference this variable
 
local myAddonLocalGlobalObject = {} --Local to the scope of this .lua file's functions (at least from my experience). 
 
function myAddonGlobalFunction( ... ) --global function to entire API; other addons can call this function
    local value = "My scope is only within this function. So I'm unique and mama loves me!"
    --Since the scope of the above variable is local, it doesn't matter that it's declared as 'value'.
    uniqueAddonName_someSetString = "I'm global, so I'm bigtime! My scope is EVERYTHING!"
end
 
local function myAddonLocalFunction( ... ) --local function; only functions in this .lua file can call this function 
    local returnVal = myAddonGlobalFunction( ... ) 
    --Calling a global function in a local one can be done, but not ALWAYS the other way around!
end

I just sort of threw this together so it may have typos. Also, please correct me if I am mistaken with any of this and let me know if you want more detail.