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

[Sasky]

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)

[Vuelhering]

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.

[LilBudyWizer]

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.

Topic: Libraries

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.

Topic: Setting Names

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.

Topic: Saved Variables

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.

Topic: Formating

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.

Topic: Globals

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.

[Joviex]

Originally Posted by LilBudyWizer 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..

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 =)

[Vicster0]

Originally Posted by Joviex 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.

[Seerah]

Originally Posted by Joviex 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?

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

[Joviex]

Originally Posted by Seerah 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!

[Stormknight]

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

MyAddon = {}
MyAddon.vars = ZO_SavedVars:NewAccountWide("MyAddon_SavedVariables", 1, nil, MyAddon.defaults)
 
MyAddon.UI = {}    -- Table for holding UI controls.
MyAddon.UI.TLW = WINDOW_MANAGER:CreateTopLevelWindow("MyAddonTopLevelFrame")
MyAddon.UI.TLW:SetAnchor(CENTER)
MyAddon.UI.TLW:SetDimensions(200, 50)
 
MyAddon.UI.WindowTitle = WINDOW_MANAGER:CreateControl("MyAddonWindowTitle", myAddonTopLevelFrame, CT_LABEL)
 
function MyAddon.WindowTitle(myText)
  MyAddon.UI.WindowTitle:SetText(myText)
end

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.

[Saucy]

Originally Posted by Joviex 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!

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

# editorconfig.org
root = true
[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[*.md]
trim_trailing_whitespace = false

file: .gitattributes

* text eol=lf

[Vicster0]

Originally Posted by Joviex 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!

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.

[LilBudyWizer]

Originally Posted by Joviex 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 =)

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.

[Seerah]

Originally Posted by LilBudyWizer One is media libraries or databases where the size can be substantial.

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

Originally Posted by LilBudyWizer 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.

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.

Originally Posted by LilBudyWizer 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 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.

[LilBudyWizer]

Originally Posted by Seerah 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.

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.

[Seerah]

Originally Posted by LilBudyWizer 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 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. 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.

Originally Posted by LilBudyWizer 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.

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.