Addon Etiquette
 

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.

Libraries
 

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.

Settings Names
 

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.

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. :)

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.

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.

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. :p

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

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

Thats actually a better solution.

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.

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.

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.

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 :D

Totally agree. Except :p 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.

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

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. :p 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.


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 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. :p Our SVN and git repositories on this site also allow you to view diffs without having to download the changes.

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.

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.

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 :D).

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. :)

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.

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.

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... :p

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

:rolleyes:

One million times this!

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.

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

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.

:)

Now I'm thinking I want code formatting like this forum has :)

Nice examples Vicster0. Ok if I copy some of that for http://www.esoui.com/downloads/info2...ddonTest.html? Was trying to make a sort of "Example for everything, in game, addon".

By all means! :)

There is no such thing as a "local global" variable. ;)

Variables are in the global scope by default, unless they are declared as local by placing the word local before the declaration of the variable.
Local variables are available to the scope they are created in and anything below that scope.

Variables should be declared local if and whenever possible. This is both to reduce the chance for collision with other leaked global variables with the same name by other authors, and for a boost in performance.

A variable should only be made global if access from outside of the file it is declared in is necessary. (Ie, referencing the function in an XML file, in-game debugging, support for other addons to have access...)

If a variable is in the global scope, it should have as unique a name as possible. This unique name should contain reference to your addon, since it's likely the user only has one addon with that name installed. ;)

What most people miss is that frame names are GLOBAL REFERENCES to that frame. These need to be uniquely named objects as well.
If some other author also cleverly decides to give their control a global name of MyFrame, whichever one is created second will overwrite the first and the two addons will break each other. (The same is true for any other global variable.)

Bah, you are correct. This is just my bad terminology... :P
At the end of the day, it is just a local variable BUT it can be local to the scope of your entire file, for instance.

This!!! Great thing to point out! You have to treat your frame names with the same level of consideration that you do any other global variable because they are exposed globally!

Honestly, I live by the rule that "It's better to be safe than sorry." If you are passing some sort of name string to a function and you are not entirely sure if it is global or local (and can't/won't do the leg work to figure it out) just use the MyAddonname_ sort of standard, as Seerah reiterated. Then you just don't have to be concerned. :P

I'll be frank. Use namespaces.

You have a bunch of stuff you want "global" put it into a class i.e. namespace.


Does LUA allow you to reference items within your namespace(s) without full qualifiers? No.


But then you are not making namespaces like Viacom.Nickelodeon.West.Post


Just be smart. You use LibAddonMenu right? Most people probablly declare it as LAM


LAM: is your namespace/entry point.


Do the same thing to wrap "globals", dont go making a


defaults = {}


in the main module space when everyone and their uncle will do the same and cause a conflict.


MyModule.defaults = {}


I prefer dot notation, though I can see the argument for simply prepends of some prefix like MM_


Either case, yes, you SHOULD mangle/prefix/tag your stuff different from everyone elses.

Yup - I agree with this. I wouldn't (personally) put too much pressure on ONLY doing it this way but I do agree with this style. I think as long as you use something to make it as unique as possible and do as Seerah said and always try to make things local whenever you can, you are at least on the right track.

Also, pro-tip, when using tools like Zgoo, namespaces can/will save you LOADS of time debugging code. :)

:eek: *cought* (backs off and checks his globals for possible retarded names and duplicates)

You're not alone...

Trust me, I rushed through developing InventoryInsight and I have been trying to balance my time between adding features and CLEANING the code lately. I know I shouldn't have any global that will interfere with other addons but they are also not necessarily standardized... So yes, even I am going back and trying to heed my own words. ;)

Agreed, this saves me loads of time and should be enough incentive for any author to want to work in this manner.

Another one to add in here is slash commands.

I ran into this recently when I (as others have mentioned) was mashing code together quickly to get my first addon working. Awesome Info. As part of this, I created a slash command of /ai

Seemed reasonable at the time, then later other authors created addons with the same two letter slash command and suddenly there was an issue. AutoInvite is one.

I changed my slash command to something longer as I was only using it during debugging anyway.


So .... worth adding a reference page on the Wiki for slash commands and another for global namespace?

I don't know whether enough authors would check it to make it worthwhile is the problem.

I admitted defeat and redid the whole addon (the messiest one), as it was easier to write it from the ground up than fix a mess.

Only 4 more to go.

Edit:
Hot off the trail of the global/local talk.

Just had my first bug report as a bank addon and mine both had the same "function commandHandler "
Which apparently led to some issues when the user typed /mb to see commands in the other addon, and got for one of my first ****ty ones.

Did a quick fix to local everything, and moving functions around so they are reffering to each other in the right sequence (of code) and now I think that problem is out of the way.

Really really need to do a rewrite though.

This is exactly how it happens! I am currently using two slash commands for both of my addons but you are entirely right, the shorter ones probably just need to go away... Two letters is far too common and can/will cause future problems with other addons, INCLUDING your own!! LOL

I'm glad you brought this up though, I will make a note for that to be one thing to fix in this major version of InventoryInsight I'm working on right now.

Dude, that's funny. I want everyone to consider what was said here for a second... ESO has been live for a very short time and technically there are only a handful of addons for this game's UI at this time (compared to say WoW). With that being said, there are ALREADY overlap issues occurring. Even with addons from the same author!!

Better the mistakes be caught now and learned than to avalanche into the future. Thanks for sharing that with us Ins!

The interaction can be total strange too. Garkin and I had a brief add-on conflict. It had to do with the lua convention of dumping unused return values to an underscore character. Inside on of Skyshards locally decared functions was.

In ESOTheater, I had for whatever unknown reason had '_' in the relative parent position when setting an anchor.
If Skyshards loaded before mine, boom. The game tired to use the value from Skyshards on the set anchor. Easy to fix but very unexpected.

Cheers,
halja

Pro-tip:

Only use '_,' during variable assignments. If your intention is to pass nothing, then pass nothing aka nil.

For example:


I believe '_' is still a variable as far as LUA is concerned...
At least, this is how I see it... :)

Nono, it was my addon and BadVolts. The reason being I think was that we both used the same code example when we made our commandHandler ;) - Edit: The wiki has a few examples using global functions instead of local as well.

Edit: Oh yea, Shardwatch apparently had the same global. Funny I've had both installed for ages and never ran into a problem with either, despite both functions named commandHandler.. So it is too now Local.

Oh, I knew what you meant! ;)

I'm only saying that, if that can happen because you both use the same template to create the function, what's to say you don't create the same function again, globally, and somewhat different in a separate addon. It has happened before. lol

Yes. _ is just as valid a variable name as any other. It should be treated with just as much care (declaring it local) as any other variable you create/use. It's just convention that people use it as a "throw-away" variable when doing assignments from function returns. You can declare _ local at the top of your file, in the main chunk, and then use it 20 times if you want. No need to declare it local every time.

Also, yes. It just worked in your testing because _ wasn't assigned to any value and equaled nil. It would work the same way if you used VariableIWantToStayNil instead of _. ;) Well, until someone else leaked the same variable as a global...


/edit: oh yeah - and you can have more than one slash command for your addon. Just have them point to the same function. Leave the short one in as a shortcut if a user doesn't have another addon installed with the same command.

Topic: Libraries
I agree with using LibStub or some way to insure an addon isn't included twice.

If a lib is optional, by all means leave the lib as a separate addon and just make sure it can handle missing the lib.

The other case I can see is when the lib changes frequently with improvements. Putting the lib as a separate addon can see faster updates of the addon -- but the addon should still contain some version of the lib.

If Minion is used by 99%+ of users and can handle dependencies, then we could go to an RPM/DEB/linux model with dependencies as separate packages. Until then, include some version if its required. Otherwise we could make a rather annoying chain the user has to follow (Addon requires some new menu lib builds on LibAddonMenu and needs that too, which needs you to get LibStub...)

Topic: Settings Names

Agree that some unified addons menu would be preferable since the list gets unwieldy to manage. Settings that you might want to change frequently should not make you go into the settings menu but have a slash command option.

Topic: Formatting

As long as it's self-consistent, it doesn't matter. When you start mixing tabs and spaces for your indenting, that's what gets annoying as tabs don't have a defined width (4 and 8 both common) so can throw the lines with spaces out of sync with the lines with tabs. If you have a collaborative addon with multiple authors working, then discuss indentation and naming conventions amongst yourselves.

Topic: Global Variables

Single table like in Vicster's post for the Addon provides the least exposure. At a minimum, it should be the addon name. If two addons have the same name, then that opens up tons of possible conflicts (ready function executed twice, confusion amongst users, files dumped in same folder, etc)

Oh yeah, you definitely can. However, I think I will be removing mine... I guess the thing here is, the entropy when you are dealing with 2-3 characters isn't much and EVENTUALLY someone is going to use the same shorthand slash command. (As in Stormknight's case for instance.) If your addon's default slash command is pretty long then maybe having a alternate with 6 or so characters would be nice and reasonable less dangerous due to the increased entropy. However, I think in some cases, likely frequent, shortening to 6 characters is really not that much better than the default. :P

Plus, I'm just saying, slash commands are kind old school... Maybe for backend dev/qa but for prod? I dunno.. lol LibAddonMenu is pretty freakin' simple... ;)

And that's coming from someone who spends the better portion of his day in a CLI... :rolleyes:

Mostly just answering the OP. I'm late to this discussion I guess.


Re dependencies: Minion doesn't check dependencies. It probably should, but that does add a level of complexity. Individual addons can have dependencies.

Since you mentioned not including optional dependencies, many addons are dependent on LibAddonMenu and embed it in the download (which you suggested addons should not do). If you want a consistent look & feel, unlike Apple with Inside Mac, ZOS has not released a set of books (or even published their interfaces) or a set of libraries to help with look and feel. Even so, look & feel is ultimately up to the programming author. If ZOS wants a consistent look and feel, they can make a good set of libraries for it and a very clear, documented API that's not "discovered by the community and entered into a wiki" and doesn't require going to hacking and reverse-engineering sites to pull their Lua code out for examination just to write a program to support their product.

Re saved variables: Generally, no addons should intentionally touch another addon's saved variables. Any updates of the original can break everything. If an addon is designed solely to massage another addon's saved variables, absent some seriously transformative results, it's probably a derivative work of the original addon author. This includes things like bugfixes.

Re formatting: An addon is for end users, not for addon programmers. If you format like ****, you are the only one who suffers as the author. If it's buggy and can't be fixed easily by others, you also suffer as the author because nobody will fix it for you. If we trust the addon API, then we should never need worry about what is in the addon code.

I'm a big fan of releasing code and allowing others to maintain. But that doesn't mean I'll be held to someone else's standard of coding.

Frankly, I think all addons should be compiled or obfuscated by default, which will prevent issues that arose in WOW where people were stealing and distributing the addons then adding beg screens for money that didn't go to the original author, and it would also help prevent issues with copyright bickering when someone "borrows" 10 lines of code or something. I will also note, the day ZOS goes the way of blizzard and forbids obfuscated code is the day I will stop distributing addons (just like I did with blizzard with the Ni Karma System, a highly-acclaimed loot distribution system way back when). Bliz basically made a claim that "Your lua code runs on our interpreter which we got from Lua.org, therefore it's an extension of our game, therefore we can make a land-grab and try to steal your copyright and tell you what you can program in our stolen language, Lua." Tons of addon authors quit the game and stopped distributing addons. (Literally, tons. Including me, and I'm skinny. :-)

Re globals: Global variables should basically not be used, because they can have serious unintended side-effects by stepping on other things. I consider globals to be a memory leak. If they are necessary, they should be hidden within a single table clearly tied to your addon (and probably sharing the same name). If I wrote the Vuel Superwarlock addon, the only variable I should use is Superwarlock, where I can embed Superwarlock.config, Superwarlock.counter, etc.

Overall a good idea. It's easy to say I'm just developing an addon all by my lonesome so what's it matter? I think that's the wrong way to view addons. It's crowd sourcing. If you're the only one that ever uses your addon then do whatever you please, but if you're going to release it then follow a few conventions.


I have mixed feelings on libraries. Kudos for Seerah getting LibStub out early for a simple, but essential, function. LibStub doesn't require you do either, just one. The library can be a separate addon or included with an addon using it. So it's more convention. I think there's two cases where it's a good idea to be a separate library. One is media libraries or databases where the size can be substantial. The other is where the library provides an interface for the user. ZAM Stats is an example of that. It's not a library, but should be. It should be using LibStub and not ZAM_Stats. It really is a library with an example of using it.

So I don't think there's an always this way or that way answer, but, rather, it depends. I think there should certainly be guidelines to help developers understand when they should choose which.


By settings names I assume you mean what displays on the system/setting menu using LibAddonMenu. I certainly have encountered wtf is that? One problem though is what the user sees in the ADD-ONS menu is the Title from the manifest. So I think you need a standard for that, like "name - version{ - author}{ - description}. Name is the directory name for the addon. Version the version number as seen on ESOUI to make it easy to check when you need to update an addon. Author incase you have a bunch of addons from the same author to facilitate getting a list to check versions against. Description for when name is cryptic. The settings should then be description if present, otherwise name. It should be clear to the user what the settings are named from the addon list. You have a Description in the manifest so any additional information you want to add can be put there.

Separately LibAddonMenu needs to expand. Personally, all that should be under settings is "ADD-ONS". Clicking that then gives you a list of addons. That, preferably, a real list rather than a menu, i.e. like a file manager. You can filter, sort on columns, and such. Selecting an addon then pops menus like now, or alternatively a custom dialog. A custom dialog just handles some configurations better. I include that here because there needs to be some standard for that list. A way to pull the needed information from an addon. Not that I expect Seerah to do that anytime soon, but, presumably that addon is going to grow. Since lots of addons are already using it the ability pull the data as it grows rather than addons having to push it makes that easier. So I think there should be a convention for including data in a standard location for use by an addon manager. LibAddonMenu isn't the only possibility there. An example of an alternative one is an addon that tracks down who is polluting the global space by enabling and disabling addons and reloading the ui.


I'm really baffled as to how Seerah avoids saved variables since, as far as I know, it's the only way to write a file. I assume Seerah actually means per character saved variables. My view is you use the simplest means possible to accomplish the task. When there is no actual sharing between characters then use per character rather than needlessly complicate it by adding subtables for users. All that accomplishes is changing the structure of the saved variables file. You can load those files into an LUA session external to the client. When there's no actual communication between characters make it clear by using the means provided.

I haven't really played with those function so I'm not sure what the parameters do. I understand it enough to use saved variables, but I'm not sure what happens with multiple calls and as a result of changing parameters when there's an existing saved variables to load. The details of that do matter. Some convention on session names, versions, defaults and profiles is needed. A convention for the name as well. Personally, addon_DB, addon_SV or addon_SavedVars where addon is the directory name for the addon. You can't really just have one global since saved variables is another. While you can pick up the variable name from the manifest it makes utilities a bit easier if you just use one.

Also within the saved variables a convention would be nice. Like if you need to share data between characters have "Characters" and "Account" keys. Account has stuff that applies to all characters while Characters has subkeys by the character name. Within those conventions such as options go in Options, history goes in History, data goes in Data, data to be imported in Import and data to be exported in Export. Export is for doing things like uploading your stats to a guild website. Import is from bring in databases such as node locations for addons such as Harvest Map. Some, like Options, should have some standards if certain options are supported, like window size and position.


Coding standards certainly. That, to me, would include naming, i.e. local variable/functions, global variables/functions, modules, keybinds, ect. Commenting as well. It should be easy for another programmer to pick up your addon. Some saves errors. Like I ran into naming a function the same as an API function that function called resulting in infinite recursion. I should have stuck them in a local table so there is no chance of such conflicts. As mentioned conventions also help with utilities. The programmer you screw may be yourself in depriving yourself of use of a handy tool.

I don't agree with stripping white space and such. Programmer automate thyself. If you want the white space stripped out then strip the white space out as you parse it. It's senseless to make the source difficult to read so a parser has an easier time at it. That's pennywise and dollar foolish. Spend hours trying to decipher illegible code to save yourself five minutes modifying the parsing process. The LUA manual lists the BNF definition of the language so you can cut and paste it into a parser. So, no, make it easy to read, not easy to parse. Conventions are just used for meta data, what's not in the code, i.e. a comment explaining what the purpose of the function is. Naming conventions are memory aids to the programmer.


There should be only one. Ok, maybe a few. It's a pointless debate across many languages. It's pointless because one variable can contain all your other globals. i.e. glob.this. glob.that and glob.theother. That said you actually need more for an addon. Your saved variables have to be global, the function you call creates them as globals. Otherwise they don't need to be. Your top level windows are global. Your key binding entry point has to be global. You need a global handle for the addon as well, logically the one global. One can debate whether than should be a table or class. Class rather complicates it for those that don't use classes. With those that do exposing a table is blasphemy. That one though should be the directory name for the addon.

I see far too much garbage polluting the global space. any()? Wtf is any? Any what? All I know is it dumps cryptic messages to the console and goes on and on and on. This is a particular problem at this stage. Documentation is incomplete and I have to browse the global table to find what I'm looking for. What I would really like to see is just one global for all addons. Every other addon then has a subtable within that. That would keep the global space as clean as possible.

I feel a few people are not understanding what I am asking for here.


Tell me the difference between the following two lines of code:


function getSomething()
function getSomething()

At fist glance, NADA. When I run this through HG to commit, it is going to tell me that line 2 is different, hence a "change" from line #1. Why?


Because it has white space (20 extra spaces) at the end of the line.


It has nothing to do with obfuscation. I am definitely not advocating using a minify, like for javascript, to pack all the code into a single line =)

I could see where this would matter... In a large project that many different people are working on.

IMO - If you are developing by yourself and/or don't use git or a similar tool to track your code changes then this is a not really a big deal. :rolleyes:

LibMediaProvider only comes with media contained in the game files by default. If anyone wants to create an extra package of media for the library to pull from, that is a separately installed addon.

For databases, just like the library code, only one set will be retained in memory. The rest will not be. If your hard drive has 500GB on it, I don't see how 1MB makes a difference. If your computer has 8GB of RAM, I don't see how 1MB of static memory makes a difference (it will even disappear when the garbage collector runs next).

Now this is not true. ZAM_Stats is a framework - an addon with an open API so that additional plugins may be created for and installed with it. It is in no way a library.

I never said that I don't use saved variables. I said that I don't use ZOS's special saved variables API. Whatever the name of your saved variable is in the .txt file, whatever you set that to in your code, that variable will be saved upon /reloadui or logout. It works the exact same way in WoW.

I have a "why" question, too. Why would you be running someone else's code through HG to commit? ;)

You mean like all the updating that Wykkyd does for the mhQuestTools for which I wrote an extension?


Everytime he updates, I have to first check for diffs in his own code.


one of his modules uses CR line endings, which makes it look like every single line changed since the module I commit uses CR+LF.


So, I first have to save the module he edited, with CR+LF, to make sure the diff runs correct.


Same for any stray whitespace, which is why, in SciTE I have a pre-time save that strips whitespace from the end of lines =)


I can deal with it, but we were, someone was, asking for standards. I consider that to be a standard, and, to the point above, nicer when you have multiple people say, working in/on a library of functionality that is shared.


If it is local and solo then do whatever the heck you want!

Something I have done with my latest addon is try to segregate the naming within my global namespace for the addon.

In it's simplest forms, where I have a namespace of MyAddon I add a table named .UI for all UI elements.

This means there is no chance of having naming issues where a UI control and a function have the same name


It helps me keep things tidy and is really handy when inspecting with zgoo.

MyAddon - the global namespace declared for the addon.
MyAddon.vars - this is the saved variables.
MyAddon.UI - this is for frames/controls.

For my projects I use two files that "define and maintain consistent coding styles" [1]. It helps me keep consistency across all projects I make. I must admit I'm not 100% sure about the differences between CR+LF and LF or when/which to use. I know CR+LF is for Window's newlines.

.gitattributes is used for Git (I'm not sure if it exist something for SVN/etc).

[1]: http://editorconfig.org/

file: .editorconfig
file: .gitattributes

I use mercurial and tfs, they both provide the same type of mechanism, however it does not fix inconsistent files using two different line feeds.


Which to the greater point is about having our establishing some standards.

Maybe I'm crazy but I feel like the "standard" you are looking for here is something that has been historically sought after in the coding world for some time...

I think the issue you are highlighting here is less of an ESO UI Modification Standardization issue and more of a global code formatting issue. In my line of work, I regularly switch between Windows, Linux, and MacOS(yes, just still Linux, I know) systems, transferring files between them all many many times just in a single day. The CR+LF or LF only is something I need to be cognizant of at all times. I feel your pain, but I don't think it's a battle that needs to be fought here.

I believe we should be focusing on standards, conventions, and techniques where it relates to the code itself and less the formatting and white space.

This is quickly turning into a conversation about Indent/Bracing styles. A conversation that I personally LOATHE.

Sounds like you need a better system =) We use all 3 platforms as well, daily, and auto-translates happen when people push Xcode up or push from VS. That is more a tooling problem -- automation.

This is ultimately why I backed off the thread. Whitespace is a standard, as is any form of code formatting. Semicolons, line breaks after { }, how many indents for a tab, etc...

And while I love XKCD, it only applies outside your studio. For my studio, and the 20 engineers I supervise, they adhere to S&P for code, commits, design documentation, sizzle work, code analysis, requirement analysis, etc...

The point is: It is fully controllable in a controllable environment.

Here, obviously not +)

The ONE thing I think we can all agree upon: Global space should be "clean" so no one is stepping on someone else.

Otherwise, yes, if you want to use LF and 8 spaces for a single tab, kudos.


If you source is open, and sharable, it will just mean that when I integrate it, I will adhere it to my standards, which will cause me local problems on any updates/merges from subsequent updates you push in the future, that I want to incorporate.

That is also, simply, a local cost benefit analysis on whether someone wants to spend that time resource because it outweighs the benefit.

Thus, my long winded post, longer, I am advocating more for "MODULARITY" and libraries.

At least with a good library, code has the potential to have a larger group work on it, with a set standard, that you can expect, versus, picking through 5x iterations of the same idea, all with a different layout and verbiage.

Right-o.

I have written coding standards for businesses and tons of procedural specifications.
And the big difference was that all those people, and me, were being paid to adhere to them.

When I, or you, or anyone is doing their own addon even if they plan on releasing it, the only obligation they have is to themselves. If they plan on making money, or having it be popular, or whatever then (and only then) they have an obligation to their users.

When they are coding in a team, then they have an obligation to their team members.

But at no point do they have an obligation to other addon programmers.

You misunderstand me. Run it through a program that strips out unnecessary white space, blank lines and comments then run the output of that program through diff. Programmer automate thyself. By the time a programmer could get through checking for extraneous white space on 100 lines a program could process millions of lines. You have a computer, use it.

What LibMediaProvider does and what all possible addons might do are two totally different topics. I was using media generically, i.e. movies, pictures and sound, and not referring specifically to LibMediaProvider. More generally I meant if a library is physically large it should be distributed separately. Media files is the only thing I can think of that might be large. Scripts certainly are not going to be. Databases could be. I think, in general, an addon should be standalone with no dependencies, but there's one exception. I wasn't talking about 1MB, but hundreds of megabytes.

With ZAM Stats it's a matter of opinion. The author could have distributed it as a library. There is absolutely nothing preventing him from doing so. We seem to both agree that's an exception and he really shouldn't have. Whether we call a framework a special type of library that is in no way a library or makes not a bit of difference to the point. My point is that the standard should be whether a user directly interacts with the addon independent of any addon using it. ZAM Stats is a prime example of that. You have configuration options that apply to all addons. It makes no sense to have 20 paths to that because you have 20 panels installed. It only makes intuitive sense to a user to configure those 20 panels through one addon that is ZAM Stats. My opinion though is it's a library, a framework is a library, a particular type of library. One of the two types of libraries it is preferable a developer distribute standalone. Physically large ones being the other exception.

I didn't know that about saved variables. Personally, it shouldn't be so. The only that should be accessible is what an addon should see. I would love to hear a compelling argument for not using those functions because arrogance is the only reason I can think of. I've been a programmer for 30 years and I've certainly engaged in my fair share of arrogance and been bitten in ass for it many times as well. Putting it in assembler seemed a good idea at the time, but ten years down road the guy stuck supporting it calls me about it and it doesn't seem such a good idea any more.

Unfortunately, there is no better system for us - I work in enterprise storage and the differences are because of going form one storage system or compute node to another and then to my workstation, a server, or my laptop. Though I do develop software to "assist" my team and myself, I am by no means a software engineer by trade thus, it's not my work. :)

As far as the rest goes, I totally agree with you. I think the objective of the standards and conventions being discussed in this thread is one of avoiding stepping-on-toes, as it where. Which obviously deals mostly with the manner in which you declare and use globals and their naming, the usages and inclusion of libraries, etc.

And of course, if you work on a team of authors - much like the matter of being a software engineer for a living - I would highly suggest discussing and deciding on standards regarding styles and whitespace... amongst yourselves. :P In a controlled environment, this is something that not only should be done, must be done. On this scale, it's basically a moot point.

I don't really see it as any different than in the enterprise. You don't have control over the programmers. Haha if you think you do in the enterprise. You can enforce standards in the enterprise. Only in your dreams. This is no different than having 3K programmers in an enterprise. You have amateur programmers. What do you think a end user writing a macro for an excel spreadsheet is? Even if you're CIO you cannot dictate from on high that everyone is going to rewrite their code to conform to your standard because you don't have the budget for it. That CEO, COO and CFO trump your ass when they can't run the cash registers in the store because you have all your programmers reformatting comments. This, really, no different than the enterprise.

I am the author of ZAM Stats. ZAM Stats is an independent addon. The user interacts directly with ZAM Stats. It has 3 base modules, and allows for more to be added. I'm starting to think that you haven't looked at how the addon works or even used it. :p Just because something has an API, doesn't mean it's a library. Just because something is modular, doesn't mean it's a library.

It's not arrogance. It's how the game works. All the API does is allow for what the ZOS devs wanted to use for their profile support. These functions weren't even in the released API, they were dug out. If I wanted to create my options on my own rather than use LAM, you wouldn't call that arrogance, for example.