| 04/24/14, 12:30 PM | #41 | ||
Join Date: Mar 2014
Posts: 42
|
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 | ||
Join Date: Apr 2014
Posts: 82
|
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 | ||||
|
Fishing Trainer
Join Date: Feb 2014
Posts: 648
|
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).
|
||||
|
|
| 04/24/14, 01:31 PM | #44 | ||
|
Fishing Trainer
Join Date: Feb 2014
Posts: 648
|
 |
||
|
|
| 04/24/14, 06:40 PM | #45 | ||
Join Date: Mar 2014
Posts: 42
|
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 | |
Join Date: Feb 2014
Posts: 128
|
||
|
|
| 04/24/14, 07:57 PM | #47 | ||
Join Date: Apr 2014
Posts: 20
|
.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 | ||
Join Date: Mar 2014
Posts: 42
|
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 | ||
Join Date: Apr 2014
Posts: 82
|
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 | ||
Join Date: Mar 2014
Posts: 42
|
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 | ||
Join Date: Mar 2014
Posts: 169
|
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 | ||
Join Date: Apr 2014
Posts: 32
|
|
||
|
|
| 04/26/14, 12:22 AM | #53 | ||
Join Date: Apr 2014
Posts: 32
|
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 | ||
Join Date: Apr 2014
Posts: 82
|
 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 | |
Join Date: Apr 2014
Posts: 32
|
||
|
|
| 04/26/14, 03:50 PM | #56 | |||
|
Fishing Trainer
Join Date: Feb 2014
Posts: 648
|
 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.
|
|||
|
|
Linear Mode
AddOn Sites
© 2014 - 2022 MMOUI
vBulletin © 2024, Jelsoft Enterprises Ltd