Thread: Addon Etiquette
View Single Post
04/20/14, 04:41 PM   #9
Joviex
 
Joviex's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 42
Originally Posted by Seerah View Post
Many people are like me. They aren't software engineers, they are teaching themselves because this is a hobby for them.
Dont think anyone said because of their day job they should get paid. I know I said my day job is engineering, and I DO get paid but that I didnt pick up the game to play engineer =)

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

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

Originally Posted by Seerah View Post
This is not anything that is enforceable across addons. I don't even use the ZOS API for creating saved variables. Instead, I do it with the much easier method that I use in WoW. You shouldn't force authors to follow a specific naming scheme for saved variables either.
Only thing I threw out there was for ONE specific variable that contained the pretty name of the addon.

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

Originally Posted by Seerah View Post
Lastly, let's discuss formatting.

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

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

True white space, not indented, or purposeful whitespace.

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

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