General Development Practices

I had a curious question for the developers of this community:

What are your general practices when it comes to coding?
I know that I generally follow a process of “minimum viable product” when I code.

For those unaware or are interested, a “minimum viable product” or “MVP” for short is the barebones essential release of a product. It does not look pretty and probably does not have every last functional piece of interactivity, but it completes the main goal.

In future iterations of the product, I would slowly add more and more features to match what my end product should be. Right now, all I want is a “proof of concept” that this idea of mine works.

Do any of you follow this model? Or do you take just a “trial and error approach”? Any suggestions for those who are new to coding and want to start establishing good habits?


1 Like

trial and error is what i do… probably too much

I’d like to pick your brain on that - what is your reasoning for T&E?

Have you tried other methods? Would you try other ones? I can see the benefit of T&E, though I can imagine it might be harder to troubleshoot if multiple issues are present (ie. fixing one thing might cause something else down the line to break).

i learned from trial and error, and ive been doing it ever since. for me, i will do small snippets for trial and error that way im not dealing with multiple bugs. i think it would be interesting to try another style

A little late to the party, but this is generally the way I develop stuff:

I take what I like to call a “Core script” approach, which means I write a core script that actually does everything. It’s kind of hard to explain.

I create a core script that reads information from add-on files and adds them to a big dump in a table.
The core script then goes around, calling methods these add-ons provide and reading information from these add-ons when it needs to.

For example, let’s take a UI. I would write a core to get add-ons that control different screens. The add-ons would provide methods for different events, i.e “Open”, “Close”, “Move”, and would change itself based off of those events, and would provide information about the screen it’s controlling.
The core would then call methods from those add-ons when things happened.

The system works pretty well for me, and it lets me rapidly prototype, and rapidly turn that prototype into a functional codebase. It makes expansion a breeze, and it’s a lovely way of doing things.

I guess it’s sort of a MVP approach, so I could have just said “Yeah, that”, but I’m not exactly sure. Anyhow, that’s how I write my code, in a nutshell. :slight_smile:

I start with either two methods: slapping code around and cross fingers it works or divide my problems into smaller pieces.

On the latter, I usually mentally list the smaller problems I need to solve to solve the bigger problem. I then divide that into smaller problems (which are written into functions) and do testing on the final script. Ensure it works, and then move on. This script is pretty much a module. Rinse and repeat until I finish the smaller problems and use the results to solve the main one.

In regards to testing, I tend to do trial and error. When it is so fast to run the script in question, I can make quick edits and then fix the errors that come out.


I suppose a good habit is that you should minimize any fallout your functions have. I define it as whatever effects the function has on the global scope. This makes them so much easier to use in any other scripts. It also makes them much easier to debug as well.