Quantcast How do authors normally design (or plan) their addon? - WoWInterface
Thread Tools Display Modes
07-22-17, 03:47 AM   #1
Layback_
An Onyxian Warder
Join Date: Feb 2016
Posts: 356
How do authors normally design (or plan) their addon?

Hi all,

For myself, I normally don't make any outlines of what my addon is going to be look like, but code it straight away.

Thus, when I re-visit my codes later, I find them really messy although I put comments for each sections.

So, I would like to ask how each authors design (or plan) their project.
(Like whether they draw a diagram, write down what features they want to achieve or write down TO-DO list)

Last edited by Layback_ : 07-22-17 at 03:49 AM.
  Reply With Quote
07-22-17, 07:44 AM   #2
Kanegasi
A Chromatic Dragonspawn
 
Kanegasi's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2007
Posts: 194
Decliner is probably my "baby" compared to the other addons I've made. I knew what I wanted it to do and I started out by throwing in some chunks of code other old addons used, then making it work. Using my JavaScript experience, I sort of "planned" my code layout with every variable at the top, then custom functions, then all the events. The addon slowly grew from there, but I made sure to keep blocks organized, such as the custom function block and the event block are alphabetized. If you meant visually, such as ingame frames, I had an idea on the layout of my options and just trial&error'd the frames until they worked okay.
  Reply With Quote
07-22-17, 02:11 PM   #3
Ketho
A Molten Giant
AddOn Author - Click to view addons
Join Date: Mar 2010
Posts: 846
Originally Posted by Layback_ View Post
For myself, I normally don't make any outlines of what my addon is going to be look like, but code it straight away.

For simple stuff and tryouts, this

But I imagine some people like Tekkub plan it much better... or so I'd like to think
https://github.com/TekNoLogic/Cork/tree/master/modules

Haven't heard of anyone drawing UML diagrams or some other way of planning/designing their wow project
  Reply With Quote
07-22-17, 03:59 PM   #4
Seerah
Fishing Trainer
 
Seerah's Avatar
WoWInterface Super Mod
Featured
Join Date: Oct 2006
Posts: 10,436
Sometimes I'll write down ideas I have for the addon to do and/or ways to code it. But that's more of a brain dump so that I don't forget anything. Or if I have an idea while working on a different bit of code, I'll write it down for later.

Otherwise, I just code as I go. I try to make my code as organized and easy to come back to as possible, so that I can make sense of it later.
__________________
"You'd be surprised how many people violate this simple principle every day of their lives and try to fit square pegs into round holes, ignoring the clear reality that Things Are As They Are." -Benjamin Hoff, The Tao of Pooh

  Reply With Quote
07-23-17, 03:24 AM   #5
Resike
A Pyroguard Emberseer
AddOn Author - Click to view addons
Join Date: Mar 2010
Posts: 1,262
I always draw a sketch of my GUI on paper (this can reveal a lot of issues), everything else is in my head/lua comments. I also keep a notepad close to myself, so i can write up ideas/bugs/whattodonext or code line numbers and stuff.
  Reply With Quote
07-23-17, 03:41 PM   #6
MunkDev
An Onyxian Warder
 
MunkDev's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2015
Posts: 380
Spaghetti coding until I start to get headaches, then clean up. Rinse and repeat.

Seriously though, I just tend to live by some principles:
  • If a piece of code is called more than once, it needs a function.
  • When you're expecting many elements that perform the same or nearly the same task, I use an object-oriented approach. Mixing in functions on widgets in Lua doesn't create much overhead, because you're only creating pointers to the original functions.
  • Split the code into multiple files that are each dedicated to solving a specific problem.
  • Error check everything and don't assume you did everything correctly and nothing's going break.
  • Code should generally be written as a story that you can almost coherently read out loud. Avoid abbreviations unless they are absolutely clear.
__________________
  Reply With Quote
07-23-17, 06:36 PM   #7
Layback_
An Onyxian Warder
Join Date: Feb 2016
Posts: 356
Hi all,

Thank you so much for such valuable comments here!

I'll keep them all in my mind when I plan my addon
  Reply With Quote
07-23-17, 08:45 PM   #8
JDoubleU00
A Rage Talon Dragon Guard
 
JDoubleU00's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2008
Posts: 306
Originally Posted by MunkDev View Post
Spaghetti coding until I start to get headaches, then clean up. Rinse and repeat.

Seriously though, I just tend to live by some principles:
  • If a piece of code is called more than once, it needs a function.
  • When you're expecting many elements that perform the same or nearly the same task, I use an object-oriented approach. Mixing in functions on widgets in Lua doesn't create much overhead, because you're only creating pointers to the original functions.
  • Split the code into multiple files that are each dedicated to solving a specific problem.
  • Error check everything and don't assume you did everything correctly and nothing's going break.
  • Code should generally be written as a story that you can almost coherently read out loud. Avoid abbreviations unless they are absolutely clear.
^^^This!!!
__________________
Author of JWExpBar and JWRepBar.


  Reply With Quote
07-31-17, 01:51 AM   #9
p3lim
A Pyroguard Emberseer
 
p3lim's Avatar
AddOn Author - Click to view addons
Join Date: Feb 2007
Posts: 1,626
Usually I start with the rough outlines of what the addon will do, I do everything in comments at first, detailing what I want it to do at any given moment and how it should react.
Then I start dry-coding it, typically something that will not compile, just to make sure I'm on the right track syntactically, then write the parts in correctly and /reload until it stops spewing errors. Here it depends if I'm using API I know already, or if I need to read documentation/FrameXML while writing it.

The direction I write it (core parts then each feature/module, or the other way) depends on the scale of the addon.
Something simple usually ends up with me writing the event handler then something that handles each event, but for something like my bag addon I dry-code how I want the modules to work then create and/or modify the core to handle the vision I had for it.

Last edited by p3lim : 07-31-17 at 01:54 AM.
  Reply With Quote
07-31-17, 11:09 AM   #10
VincentSDSH
Non-Canadian Luzer!
 
VincentSDSH's Avatar
AddOn Author - Click to view addons
Join Date: Jun 2006
Posts: 301
I tend to follow Iterative Design principles, so I start with two feature lists must-have and really-want. Alpha-testing begins when the must-have list is feature-complete, Beta-testing when the really-want list is feature-complete-for-all-retained-features, Beta finishes after all optimization is complete plus a reasonable period of time as determined by # of Beta-testers and project complexity.

I start with a wire-frame architecture that's laid out spatially, with function/method notations and data vectors. This helps spot problems in the logic structure (and it's easy to explain to others) and that spacial arrangement becomes the initial form of file / module isolation and grouping-for-synergy.

The Iterative part of Iterative Design means you build the most-used/most-critical infrastructure pieces first so that any problems are resolved while in proof-of-concept and will be tested innumerable times through the development phase.

Coding starts with an absolute minimalist "do nothing" shell to sure all of the files, modules, and libraries are playing together w/o errors.

Then an absolute minimalist framework for any communication code, module data transfer, and data-display.

Then an absolute minimalist framework of the core concept, doing just enough to serve as a proof-of-concept.

Then a rough draft that explains how everything works to a user. This makes you look at the project from the opposite end and will highlight flaws in logic or features, and show when new feature or functions would be needed for consistency or eliminating user-headaches.

Then I go back to the architecture and see if I can get where I want to go from where I'm at. Sometimes it's yes, sometimes it's no. Then you either sacrifice some wants or you refactor to get it. This step is repeated after every cycle.

Configuration layout is roughed and Data Display is refined in during Alpha-testing to get user feedback.
__________________
AddonsNEW Executive Assistant User Configurable To-Do ListLegible Mail Choose the Font for Your Mail
  Reply With Quote
08-01-17, 11:15 PM   #11
Layback_
An Onyxian Warder
Join Date: Feb 2016
Posts: 356
Glad to see more comments being added

Many thanks to JDoubleU00, p3lim and VincentSDSH as well!

I guess all these comments are valuable not only for addon authoring, but for programming in general


Again,

Thank you so much to all for sharing these ideas
  Reply With Quote

WoWInterface » Developer Discussions » General Authoring Discussion » How do authors normally design (or plan) their addon?

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off