inevitable bug singularity-please help me!!

I'll try to avoid talking about how this seems to happen on my real life too (basicly great things ruined by minor aparently unavoidable details)


first the general description, aparently every project I work intensivelly on reachs a point that there are so many hidden bugs it stop working, and no matter how much I debug it, no matter how many bugs I find and correct it still won't function the way it was suposed to


it has happened in just about all projects I saw poatentil of becomming comercial, andlots of my personal ones too

would anyone have any advice on avoiding the bug singularity? any recomended code organisation, procedures in developing the flux of information, ways to easilly check where the casue of a problem is etc , anything I could do to steer away from this horrid doom...

Here's how I combat this problem when scripts become more complex...

1) Name all variables - avoid magic numbers in functions/events, used named variables to improve clarity and readability. Choose names for thes globals that explain their function/intent.

2) Use functions - extract and parameterize all repeated control flow into functions.

3) Use multiple scripts - separate out logically separate functionality into separate scripts. Use one master controller script and use link messages from that script to drive all the slave scripts - use named protocol commands as in (1). Make the "slave" scripts as "dumb" as possible.

4) Document everything - anything that is not absolutely trivially clear in intent should be
commented, or you will forget what you did and why you did it in a few days.

5) Test incrementally - add one major piece of functionality at a time and test this exhaustively before moving on.

I'm sure others will have more to add, but those are the points that come to mind for me.

Regards,
/esc

I use "sensible" names for all my variables. There are some, like i say, that I always, and only, use for counters that might not be instantly obvious to everyone, but I know it's always a counter.

I use name, id, chan, msg, num, len etc. for specific, and hopefully obvious things. I thus know (and usually, but not always) remember to avoid them for globals. I know there are people that suggest putting g_ on the front of every global, but meh, I've never bothered.

Plan first, code second. Build in way points. It's pretty much what Escort said about getting one block of functionality right, then adding another. But... sit down, think about what the tasks you've got to achieve with your script are. Look at places where you stop and check it's working, even if it's not actually quite your mainstream code. I was writing a danceball for someone yesterday... It needed to update the list and offer access to lists longer than 12 items smoothly. I wrote that chunk of code, and put in something that would initially list all dances and the various next/back buttons so I could check that was working properly. That listing got ripped out, but it was a good couple of lines of debugging. Then I moved on to putting blocks of 12 into a dialog box. Then to getting permissions and starting/stopping anims.

Write in debugging. I've seen, and worked with, people that have a debug function. I tend not to, I write them in with llOwnerSay() as and when and more deliberately WHERE needed. Can't work out why this if... doesn't appear to fire? Copy the statement into an llOwnerSay((string)expression) and see what you get. Put another one *inside* the if that says it's fired and so on. Writing them on the hoof like that I can see where it is working and where it isn't, and gradually narrow down the code. There are times (hopefully not often) where I've had to put in such a debug line between each line so I really can track what's going on when it's not doing what I expect.

Ah yes, debug code! As Eloise mentioned, debug code is essential to really understand what's going on. I have the following global and function in almost all my pre-production scripts, and step-by-step check that all calculated values are as I expect.

integer DEBUG = TRUE;

debug(string message) {
    if (DEBUG) {
        llSay(DEBUG_CHANNEL, message);
   }
}

As Escort and Eloise have both said, be logical and sensible in your approach.

Analyse the problem and design a first cut solution.
That can then be iteratively enhanced (not tweaked) as you improve the design.
If you have got to the point where you have to make that many tweaks then either your analysis was flawed or your requirements have changed.

Dont reinvent the wheel each time, Build up a library of reuseable TESTED components.
Use meaningful descriptive and UNIQUE variable names
Break the code down into functions and test in isolation as much as possible.
COMMENT the code!
Output debug data, if you are using Scite-Ez you can even #if so it can be automatically removed before uploading when you are happy.