How do authors normally design (or plan) their addon?

[Layback_]

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)

[Kanegasi]

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.

[Ketho]

Originally Posted by Layback_ 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

[Seerah]

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.

[Resike]

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.

[MunkDev]

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.

[Layback_]

Hi all,

Thank you so much for such valuable comments here!

I'll keep them all in my mind when I plan my addon

[JDoubleU00]

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

[p3lim]

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.

[VincentSDSH]

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.

[Layback_]

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