Addon Etiquette

[NonameFTW]

Is there any discussion about how Authors SHOULD built their addons yet ? As like in all programming languages there are things that you CAN do and things that you SHOULD do. I can imagine that over the time the author community for TESO needs some standarts on how to implement your addon to get the maximum amount off compability and usabillity.

Myself I'm not an author (yet (mabye)) and I don't have much experience with lua and such a community like this. But I feel that all authors should have a discussion on how they can work together more efficiently without loosing their own independence.

I'm talking about the idea of creating libraries and some basic addons that every addon>user< almost has to use.
(https://en.wikipedia.org/wiki/Request_for_Comments)

Examples: SkyUI in Skyrim. It was so popular that at some point the devs started implementing tools that other addons used. Same with SKSE. Almost no addon from some point on ran without SKSE.

I'm also talking about ways on how you SHOULD implement a feature to work as good as possible with other addons. An Etiquette.

These ways are common to occur and should be discussed as soon as possible.


To get the discussion going I will start with my own Ideas. Please feel free to post you own Idea on what the community needs to do to get good standarts.


This section of the post below is up for anyone to change. Ask a moderator.

Summary and Discussions Status Topic: Libraries Proposition: - Libraries should use a common folder and addon authors should not include the libraries in their addon zip files. Instead Minion should watch over needed libraries. - Addon authors should have to make sure that minion and other addons know the needed libraries of their addons. - libraries should be a standalone ressource Current Discussion Status: Solution found. Further opinions are still accepted. Seerah explained that there is already a better system in place (That new libraries could adapt). A library registers with LibStub as it loads. If you have 5 addons installed, for example, that all use LibAddonMenu-1.0, then all five instances of LAM make a call to LibStub, passing along their version numbers. LibStub only accepts the library with the most recent version number and discards the rest. What does this mean for a user? They may have 5 copies of LAM installed inside their addons, but only 1 is being used. Topic: Settings Names Proposition: Authors should not use their Username as Settings Name because it creates confusion. Current Discussion Status: Open. Better Solution has to be found. Seerah explained that he/she proposed for a long time that authors should condense their addons in one settings panel and that some authors are not naming their addons in one series name. Now, here come conventions for certain circumstances. If you addon has no settings, and you only want to put a description in your settings panel, don't create a panel for your addon. If your addon only has one or two settings that could easily be done through slash commands instead, don't create a panel for your addon. If the settings for your addon are complicated, or would have better usability if presented in a different format that LAM provides, don't create a panel for your addon. Create your own options GUI that users can open with a slash-command and/or keybind. NonameFTW stated that naming settings names after the authors username can get confusing later on and that different addons should use different settings panels. It's not confusing YET to have these kind of username named settings. But there will be players who are gonna heavily modify their interface with HUNDREDS of addons. Now try to think of the situation here: This user would have thousands of settings he has to manage. This is not the problem. The problem comes down when multiple addons with totally different purpose use the same settings menu. You then have about 60 settings menus. Not the problem. The problem is when you have 60 settings menus which do not tell you which settings are inside. I think that such a user would rather like to have 200 settings menus which tell him excatly what settings are inside than to click through 60 settings menus and scroll through them. The discussion went on to the conclusion that a addon settings interface for all addons would be the best solution. Topic: Saved Variables Proposition: What would be nice is if a standard was established, like, if you are going to use non-global/accountwide saved settings, you should have a variable in your savedvariable table called "pretty name" or something similar. This would allow other tool(s) to present settings for manipulation in a much more readable and trackable way. Current Discussion Status: Open. Seerah disagreed. Topic: Formatting Proposition: Tabs, not spaces (though completely up to whomever), I strip all extra white space and I use CR+LF for EOLs. The above things allow me to do kdiffs very easily without getting a lot of "non" changed changes, especially the white space strip. Current Discussion Status: Open. Seerah disagreed. Joviex explained the proposition further. Topic: Global Variables Proposition: .... the biggest concern ANYONE should have regarding the standards/conventions being used with addon development would be poorly named global variables. I couldn't care less how awkward and convoluted your globals name is as long as it is unique enough to not pose potential overlaps with the default UI and other addons. As for your locals, you could obfuscate them to a letter table for all I care, tbh... Current Discussion Status: Open. Vicster0 gave some examples.

[NonameFTW]

Another Idea I suggest is to use common folder for libraries if possible. Some libraries already use the folder "libs" and in my opinion it would be a good Idea for library authors to get a common agreement on that to make it easier for addon authors and prevent redundancy.

As far as I know Minion does check dependencies. I GUESS (don't know) that its through the description txt file. But I didn't work through the material so I don't know. I also don't know if the declaration is actually necessary for the API so bare with me if the following is bull****.

In this case two things should be standart:

- Authors of addons that use specific libraries are agreeing on declaring the dependency of their addon for minion and every other addon. This should be a absolut MUST! Addon authors should not be allowed to use a library without doing so. Posting an addon that uses any external ressource without declaring its dependency should be removed from esoui after one warning.

- Authors of addons and libraries should work in such a way that minion can install all necessary libraries by itself. Addon authors therefore should NOT implement the library in their own zip file and library authors should programm their project as standalone ressource that every addon can use.

As always this is a SUGGESTION up for discussion.

[NonameFTW]

At the moment Authors want to consolidate the addons they are making under one settings menu. In general it's a good Idea to save some space. But the following problem will occur later on in my opinion.
The thing is that authors use their username for these settings menus instead of addonnames or addonseriesnames.
One thing everyone will have to get their head around on is: Until authors start to use a common (custom) addon menu interface noone will be able to prevent that users will get a looong row of settings.

So if you then have a long row of usernames from authors instead of addonnames this behaviour will get quite annoying very quick. You don't want to remember all the authors who created these things and you don't want to search for a setting through all these useless names. Making TESO addons is not a popularity contest!

So it would be a good thing in my opinion if authors started to use the addonname as a setting name. If it's part of series then use the Series name.

[Stormknight]

There are already some libraries that are in common use, so we're already headed there.

The wiki is being updated regularly and includes example code.

Ultimately it's going to take a while as people have jobs and want to play the game also.

[Joviex]

Originally Posted by NonameFTW So it would be a good thing in my opinion if authors started to use the addonname as a setting name. If it's part of series then use the Series name.

Totally agree on this point. Right now the add-On transfer settings tool I wrote presents the saved variables, but the variable names are pretty ugly in some cases.

What would be nice is if a standard was established, like, if you are going to use non-global/accountwide saved settings, you should have a variable in your savedvariable table called "pretty name" or something similar.

This would allow other tool(s) to present settings for manipulation in a much more readable and trackable way.

Just one example of standards. I also use standards as I use at my day job. Tabs, not spaces (though completely up to whomever), I strip all extra white space and I use CR+LF for EOLs.

The above things allow me to do kdiffs very easily without getting a lot of "non" changed changes, especially the white space strip.

Originally Posted by Stormknight Ultimately it's going to take a while as people have jobs and want to play the game also.

And exactly this.

I am a sw engineer by day, and I really want to play the game LOL. I think I have one character @ level 12 (my highest) and that was just from sheer testing of the quest tracker. o.0

I really enjoy the game, and I want to help others enjoy it too, and if there are standards that would be great, but no one is really getting paid. Donations are nice =) but I dont even ask for them.

So, its not a job is what I am saying.

[Seerah]

I am a music teacher by day, not a coder. Everything I have learned I have taught myself or picked up from other authors/addons, along with 7 or 8 years of writing addons for WoW.

Many people are like me. They aren't software engineers, they are teaching themselves because this is a hobby for them. Making them also learn standards/rules and adhere to them is going to be another layer you are putting on them for something that they are doing in their free time for fun.

That does not mean that I don't disagree with all of your ideas. But what you propose should come from convention, not rules. And conventions take time to develop, as more authors adopt them for their addons and more new authors learn from viewing those addons.

---------------

Let's talk about libraries first.

Placing libraries into a libs folder inside the addon folder is a convention brought over by authors from WoW. The addon loads and works just the same whether the folder is called libraries, StuffMyAddonNeedsToWork, or doesn't exist at all (with the libraries in the top level of the addon folder itself). To users, this doesn't matter at all. And to other authors, it shouldn't either.

Installing libraries as standalone and not including them in the main addon itself is not a good idea. Even over in WoW, it was discouraged and for those that wanted to install their addons this way, it was stressed that they should only do this if they were "power users" and "knew what they were doing". (Now, I do create my libraries so that they may be used as standalone if the user or author so chooses to install them this way, or the author may pull the actual library code's folder out to embed in their addon.) To users, standalone libraries give them a headache of worrying why an addon isn't working if they've accidentally disabled or uninstalled a library that they didn't know the addon uses. Also, to users, it either forces them to use Minion to install their addons or suffer the consequences of needing to make sure they have everything installed that they need. Really, addons should just work.

This brings me to my next point. I have ported LibStub over to ESO for the purpose of creating libraries that may be embedded. Any author that creates a library *should* use LibStub in their library. (But if they want to code this into their libraries themselves instead of use LibStub, whatever.) A library registers with LibStub as it loads. If you have 5 addons installed, for example, that all use LibAddonMenu-1.0, then all five instances of LAM make a call to LibStub, passing along their version numbers. LibStub only accepts the library with the most recent version number and discards the rest. What does this mean for a user? They may have 5 copies of LAM installed inside their addons, but only 1 is being used. What of the extra 60kb of memory on your hard drive from the other four? What does it really matter, if you have a 500GB hard drive?

----------------

Now, let's talk the settings menu.

I agree that the scroll menu should not get too long. From day 1, I've been saying that authors should condense their addons into one settings panel, if possible. I have been placing the settings from all of my ZAM addons into one panel as an example. This is easier to do if your addons follow a naming scheme, as mine do. Some authors choose to be more creative with their addons names or don't wish to brand them with a naming scheme. These authors, if they wish to condense their settings onto one panel, may be those who name their panel after their username. That doesn't mean that they're turning this into a popularity contest. It just means that they're saving users some room. And, so long as they tell users where to find their settings panel, what does it matter?

Now, here come conventions for certain circumstances.

• If you addon has no settings, and you only want to put a description in your settings panel, don't create a panel for your addon.
• If your addon only has one or two settings that could easily be done through slash commands instead, don't create a panel for your addon.
• If the settings for your addon are complicated, or would have better usability if presented in a different format that LAM provides, don't create a panel for your addon. Create your own options GUI that users can open with a slash-command and/or keybind.

----------------

Next, let's discuss saved variables.

This is not anything that is enforceable across addons. I don't even use the ZOS API for creating saved variables. Instead, I do it with the much easier method that I use in WoW. You shouldn't force authors to follow a specific naming scheme for saved variables either. What if they want more than one saved variable? (Yes, I realize that saved variables can be a table, but some authors want two distinctly separate saved tables.) What if their addon is named My_Addon2, but they just want their saved variables named MyAddonDB? What if the only thing an author wants to save is whether or not the addon has been loaded for the first time already? Then their saved variable name may be MyAddonLoaded. To users, saved variable names do not matter. To other authors, saved variable names, do not matter. To Joviex's addon, and his addon only, they matter. A standard or convention should not be created for one use-case.

Instead, I keep saying that it should be up to the addon authors themselves to place profile support within their addons. If Joviex wants to write a library that makes that easier, they may adopt profile support faster. Me, if I make profiles in my addons, I'll just do it based on the same way I did it in the past with WoW. This is what I know, this is what I'm comfortable with, and this is something that works.

-----------------

Lastly, let's discuss formatting.

I use tabs myself. Others use spaces. Those that use spaces may vary from 2 to 4 to 5... It's all about personal preference. Tab size may vary from editor to editor, but spaces stay the same. This is not something that needs a "standard".

Semi-colons at the end of lines/commands are not necessary in Lua, yet some authors choose to include them from experience coding in other languages. Semi-colons don't hurt any, so it does't matter whether they're included or not. This is not something that needs a "standard".

Some authors choose to put in extra white space for readability and/or separation. So, it may add 1b to your file size, but it adds 0b to your addon's memory usage. Extra white space is not something that needs a "standard".

[NonameFTW]

Originally Posted by Seerah A library registers with LibStub as it loads. If you have 5 addons installed, for example, that all use LibAddonMenu-1.0, then all five instances of LAM make a call to LibStub, passing along their version numbers. LibStub only accepts the library with the most recent version number and discards the rest. What does this mean for a user? They may have 5 copies of LAM installed inside their addons, but only 1 is being used. What of the extra 60kb of memory on your hard drive from the other four? What does it really matter, if you have a 500GB hard drive?

Thats actually a better solution.

Originally Posted by Seerah Now, let's talk the settings menu. .....

Some authors may create mutliple addon that are totally unrelated. In this case I would disagree with you. One author should be "allowed" to create more than settings menu. It's not confusing YET to have these kind of username named settings. But there will be players who are gonna heavily modify their interface with HUNDREDS of addons.
Now try to think of the situation here: This user would have thousands of settings he has to manage. This is not the problem. The problem comes down when multiple addons with totally different purpose use the same settings menu. You then have about 60 settings menus. Not the problem. The problem is when you have 60 settings menus which do not tell you which settings are inside.
I think that such a user would rather like to have 200 settings menus which tell him excatly what settings are inside than to click through 60 settings menus and scroll through them.

Again! I'm not against consolidating multiple addons into one settings menu. But there should be another logic behind it. One setting menu per Addon or Addonseries. Not one settings menu per author.


Of course the whole situation is a crappy solution. The best would be a integrated Interface which would create just one settings menu called "addon settings" or something. This would open up a new window with all addons that use the library. Each addon would have their name on the left side and be clickable. I think this solution would solve the whole problem because most authors would start to use the addon names by themselves.

I've seen in the comment section of you library that you're considering this for version 2.0 . This would defenitly help the whole community!


__________

Btw in general:

The only enforced standarts can be applied by zenimax. What you call conventions and what I mean with standarts is the same.

[Seerah]

I said that if it was possible*, then it would only be done for a total rewrite of the entire library - hence, version 2.0. I never said that I was already considering creating a version 2.0 or planning out features/changes for it.

Also, I never said that an author should be forced to only use one settings panel. I said that I encourage it, "if possible". Also related to your paranoia about the addons list, I also gave three scenarios where an author should NOT use LAM. And even still, addon authors that want options panels DON'T have to use LAM at all. And not all addons will have settings to configure. ZAM_Notebook has 0, for example.


*Adding a header/button to the Settings menu automatically creates a panel for it that opens when you click this header/button as per the game's API. So if I do make a 2.0, it may not be located in that menu at all.

[Joviex]

Originally Posted by Seerah Many people are like me. They aren't software engineers, they are teaching themselves because this is a hobby for them.

Dont think anyone said because of their day job they should get paid. I know I said my day job is engineering, and I DO get paid but that I didnt pick up the game to play engineer =)

Just saying having some reduced entry points, like shared code/libs, would go a long way to rapid development versus writting the same code over and over and over and over.... that everyone else is doing.

Which I think when you do that, from my experience as an engineer (20 years), it is always better to have a set way of doing things.

Originally Posted by Seerah This is not anything that is enforceable across addons. I don't even use the ZOS API for creating saved variables. Instead, I do it with the much easier method that I use in WoW. You shouldn't force authors to follow a specific naming scheme for saved variables either.

Only thing I threw out there was for ONE specific variable that contained the pretty name of the addon.

But that is completely selfish for my recent plugin so that instead of posting the SavedVariable tabe key, it would look for this pretty name and present that, so things like "IIB_Save" actually show up as "Inventory Item Borders" so someone knows what they are transferring

Originally Posted by Seerah Lastly, let's discuss formatting. I use tabs myself. Others use spaces. Those that use spaces may vary from 2 to 4 to 5... It's all about personal preference. Tab size may vary from editor to editor, but spaces stay the same. This is not something that needs a "standard". ... Extra white space is not something that needs a "standard".

Totally agree. Except it is not about white space adding "space".

It makes kdiff(s) or any diff(s) run better without a lot of false positives on changesets. And when I say white space, I mean white space like a line with nothing but a tabspace on it, or 10+ spaces at the end of a code line.

True white space, not indented, or purposeful whitespace.

I know, not everyone uses a repository to push changes; again, I do, so probably selfish, but my preference is to simply have "smart" commits with actual changes to code versus a bunch of changesets that were zero merges except white space.

I dont think anything is "throw all your toys on the ground go home" just some thoughts on having a cleaner, potentially faster development environment for some.

[Seerah]

Originally Posted by Joviex Dont think anyone said because of their day job they should get paid. I know I said my day job is engineering, and I DO get paid but that I didnt pick up the game to play engineer =)

I think you need to re-read what I wrote if you think that is what I was saying.

Just saying having some reduced entry points, like shared code/libs, would go a long way to rapid development versus writting the same code over and over and over and over.... that everyone else is doing. Which I think when you do that, from my experience as an engineer (20 years), it is always better to have a set way of doing things.

We do already have libs created for this purpose. If you are writing an addon, and the code you are putting in there makes you think "hmm... I can think of 10 different addons that could use this, too." then turn it into a library. If that doesn't occur to you, or if the idea of writing a library is a little scary, then it's not really a big deal. My system has 8GB of RAM. A miniscule performance boost is not going to be noticed.

If you're talking about ways to write code as in templates for authors to use, that is free for anyone to put up onto the wiki.

Totally agree. Except it is not about white space adding "space". It makes kdiff(s) or any diff(s) run better without a lot of false positives on changesets. And when I say white space, I mean white space like a line with nothing but a tabspace on it, or 10+ spaces at the end of a code line. True white space, not indented, or purposeful whitespace.

I use Notepad++. It auto-indents new lines according to what is above it. If I have a blank line with a tab in it, that's because it was put there by the program, not me. This is probably the case with 95% of what you see out there.

I know, not everyone uses a repository to push changes; again, I do, so probably selfish, but my preference is to simply have "smart" commits with actual changes to code versus a bunch of changesets that were zero merges except white space.

I do use a repository. I also don't make a commit if nothing was actually changed. I certainly don't *push* a commit for users to download without some reason to increment the version number or put in the changelog. Our SVN and git repositories on this site also allow you to view diffs without having to download the changes.

I dont think anything is "throw all your toys on the ground go home" just some thoughts on having a cleaner, potentially faster development environment for some.

Of course. My goal, as a teacher, is to help people learn and see things from all sides. If someone has templates to copy from or libraries to use for most everything, they won't actually learn about what they're dong. They have an upside and a downside. I (and others) always encourage new authors to stay away from libraries/frameworks when first learning how to make addons. This way, they only have to learn one API and they learn how things work and why.

[Joviex]

heh!

No worries. Your code is some of the most helpful for me.

And it is not a deal breaker by any means.

Unfortunately, you have SVN and GIT but no BB support.

I use HG and TFS (no support for that obviously) but HG would be nice =)

And I think I am in the process of making a community lib for things like CHAIN, etc... There is a lot of stuff in wykkyds framework that would be nice, but loading all the other stuff (Bazgrims toolbar, etc...) is heavy handed.

Some nice UI support (not settings menu), general string support, blah blah.... would be keen.

[thelegendaryof]

Some good points floating around here. I have one thing I might add / aproof of as well:

I also feel like that Addons Settings tend to use up to much space right now (especially if you have to many of them installed ).

However, if LibAddonMenu would put up only one Main-Entry in the native Settings-Section named like "Addon-Settings" and then add an List-Box on the top of the Right-Side with all the addons setting names like they're used right now (just in the List-Box) it might be way more accessible and save up Screenspace after all.

And it would make it clear that those are Addon-Settings after all.

And I guess it wouldn't be as big of a change as it would require any API-Changes. What do you think about that idea Seerah?

Edit:

Retard me, next time I should check your comment-section beforehand. http://www.esoui.com/downloads/info7....html#comments.

I'd be willing to volunteer for it if you dont have time or don't want to add it right now (as I feel like it would be a big improvement). But I wouldn't want to do it without your approvement or official patch thereafter as I'd find that a bit of a waste of time if it 's unofficial and not pushed out. I could understand if you want to do it yourself thought! After all coding is something personal and needs to make fun - and sometimes you don't feel like others should mess with your code after all.

[ins]

Re Addons, think we already had a discussion on it : http://www.esoui.com/forums/showthread.php?t=507
Well, tried to anyway.

Seeing my addon menu getting a bit populated now.

Personally I like / commands, but I can certainly understand users wanting to use the GUI as the number of options in one of my addons has grown quite a lot. But I would rather just have an option like
/jy setup that will then trigger XML Frames to configure that addon.

At least until we can get our own "Sub-config" setup, a bit like how Ace3 (I think it was) had all the addon with options in its own little GUI.



On Libraries, been thinking about making one so I grabbed LibStub to get an idea on how to go ahead.
Hopefully will figure it out.

[Seerah]

Now that you guys are making me think about, I may have an idea for LibAddonMenu-2.0, but I'll need to investigate into it and see what ugly hacks are needed. Once summer hits, I'll have more time on my hands. Not sure how much work I'll have at school.

For LibStub, the documentation is pretty solid on the download page. There's also a thread around here somewhere where someone wrote it all out even more verbosely.

[skyraker]

Seriously, when I saw this topic I thought it was another 'what things shouldn't we do with our addons' type of thread.

I like the discussion going on though. I actually like the idea of addons being able to share one settings menu entry but I can see where some people wouldn't find it as easy. I never originally planned on using LibAddonMenu to create a settings menu entry, but did so after requests from users (and my ineptness with adding things like slider controls to my own menu window.

[Vicster0]

Originally Posted by skyraker Seriously, when I saw this topic I thought it was another 'what things shouldn't we do with our addons' type of thread. I like the discussion going on though. I actually like the idea of addons being able to share one settings menu entry but I can see where some people wouldn't find it as easy. I never originally planned on using LibAddonMenu to create a settings menu entry, but did so after requests from users (and my ineptness with adding things like slider controls to my own menu window.

Ha, I remember the thread you are talking about...

Great discussion going on here! I may be off my rocker, but I seriously think the biggest concern ANYONE should have regarding the standards/conventions being used with addon development would be poorly named global variables. I couldn't care less how awkward and convoluted your globals name is as long as it is unique enough to not pose potential overlaps with the default UI and other addons. As for your locals, you could obfuscate them to a letter table for all I care, tbh...

[Seerah]

Originally Posted by Vicster0 I may be off my rocker, but I seriously think the biggest concern ANYONE should have regarding the standards/conventions being used with addon development would be poorly named global variables.

One million times this!

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

[ins]

Originally Posted by Seerah One million times this!

Starting to move to Local for everything I can. Think I should update the "AppTest" I made, as it was a nice learning exercise - especially with some of the feedback I got when doing it.


One thing that is starting to seem annoying to me, even though it shouldn't, is that we are getting into an AppStore issue with 15 version of basically the same addon for everything. Yes, I know each have their approach to it and its good to have options but, yea, I really shouldn't think like that, Healthy competition makes for better addon scene overall. And well most of the things being made are more like simple hacks. Course, the really good/big ones will not have much "competition", like FTC, Zgoo, Wykkyds suite etc..

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