04/24/14, 12:30 PM | #41 | |
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 =) |
||
04/24/14, 01:08 PM | #42 | |
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. |
||
04/24/14, 01:30 PM | #43 | ||
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).
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. |
|||
04/24/14, 01:31 PM | #44 |
04/24/14, 06:40 PM | #45 | |
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! |
||
04/24/14, 07:35 PM | #46 |
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 Lua Code:
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. |
|
04/24/14, 07:57 PM | #47 | |
.gitattributes is used for Git (I'm not sure if it exist something for SVN/etc). [1]: http://editorconfig.org/ file: .editorconfig Code:
# 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 Code:
* text eol=lf |
||
04/24/14, 11:49 PM | #48 | |
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. |
||
04/25/14, 05:24 AM | #49 | |
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. |
||
04/25/14, 02:08 PM | #50 | |
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. |
||
04/25/14, 05:17 PM | #51 | |
|
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. |
|
04/25/14, 11:12 PM | #52 | |
|
|
|
04/26/14, 12:22 AM | #53 | |
|
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. |
|
04/26/14, 12:27 AM | #54 | |
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. |
||
04/26/14, 03:01 AM | #55 |
|
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.
|
04/26/14, 03:50 PM | #56 | ||
|
|||
ESOUI » Developer Discussions » General Authoring Discussion » Addon Etiquette |
«
Previous Thread
|
Next Thread
»
|
Display Modes |
Linear Mode |
Switch to Hybrid Mode |
Switch to Threaded Mode |
|
|