I have used just about every one of those pieces of advice in my debugging. Seeing as I am highly fallible in my own coding processes, and have clearly wasted at least half my time debugging, I have learned from my mistakes aswell.
I'd like to add to that list with some suggestions of my own:
1) DebugLog is the best tool ever made. The example tells you that you can use it to write down if your code has reached a point of execution, but it has far more uses too. I often use it for collecting data so I can pinpoint at what moment things begin to screw up. By mixing it with KeyHit() and KeyDown() functions in If statements you can also use it to record your data so you can see what happens to your numbers at particular points.
2) Any formula's and calculations that have any complexity over x = x+1 should be written out on paper first. I can't tell you how many times I have decided I know how to do something in my head only to waste hours tweaking it and getting nothing before resorting to sitting and working it out on paper. A tip for working on formula's is that you must decide EXACTLY what you want it to do before you can do it.
3) Don't tweak, understand. Yeah, I know its a pain, but if you don't understand why something doesn't work you cannot figure out how to fix it. Often times if something doesn't work your initial thoughts are to just move some stuff around as that might be the problem. If it didn't work the first time then write it out on paper as sitting for an hour analyzing the problem is less frustrating than sitting for an hour moving code around and yelling at the computer.
4)Make your code flexible. Oh, I CANNOT stress this enough. More than once I have spent days changing something that if I had just put in originally they would have taken a few seconds. If you put code in you always have to think, how much work will it be to modify this, or that. Even if you don't plan on doing it, if the answer seems like a lot more than you expect you probably need a better design. I once spent over a week reconfiguring something in a turn based game I made because the current functions couldn't work with a player being eliminated. When a few If Else statements would have cured it at the time I made the code.
5) Finally, design aspects ahead of time. A common pitfall of inexperienced programmers (myself included) is to start planning a project before they know how to do everything. The idea behind this is that they will learn how to do what they need to do when they get to that part. This sounds all well and good, until you come to that time and when you learn that they way you thought something worked isn't correct, and it will require you to rework code to get it to fit in. So if you know your going to need to do something for a project that you don't know how to do yet AT LEAST look over how you should do it to make sure there aren't any surprises later on.
I'm not a very experienced programmer myself, however, I have made alot of mistakes that I have tried to learn from. Hopefully this and the original article can save some time!
I'd like to add to that list with some suggestions of my own:
1) DebugLog is the best tool ever made. The example tells you that you can use it to write down if your code has reached a point of execution, but it has far more uses too. I often use it for collecting data so I can pinpoint at what moment things begin to screw up. By mixing it with KeyHit() and KeyDown() functions in If statements you can also use it to record your data so you can see what happens to your numbers at particular points.
2) Any formula's and calculations that have any complexity over x = x+1 should be written out on paper first. I can't tell you how many times I have decided I know how to do something in my head only to waste hours tweaking it and getting nothing before resorting to sitting and working it out on paper. A tip for working on formula's is that you must decide EXACTLY what you want it to do before you can do it.
3) Don't tweak, understand. Yeah, I know its a pain, but if you don't understand why something doesn't work you cannot figure out how to fix it. Often times if something doesn't work your initial thoughts are to just move some stuff around as that might be the problem. If it didn't work the first time then write it out on paper as sitting for an hour analyzing the problem is less frustrating than sitting for an hour moving code around and yelling at the computer.
4)Make your code flexible. Oh, I CANNOT stress this enough. More than once I have spent days changing something that if I had just put in originally they would have taken a few seconds. If you put code in you always have to think, how much work will it be to modify this, or that. Even if you don't plan on doing it, if the answer seems like a lot more than you expect you probably need a better design. I once spent over a week reconfiguring something in a turn based game I made because the current functions couldn't work with a player being eliminated. When a few If Else statements would have cured it at the time I made the code.
5) Finally, design aspects ahead of time. A common pitfall of inexperienced programmers (myself included) is to start planning a project before they know how to do everything. The idea behind this is that they will learn how to do what they need to do when they get to that part. This sounds all well and good, until you come to that time and when you learn that they way you thought something worked isn't correct, and it will require you to rework code to get it to fit in. So if you know your going to need to do something for a project that you don't know how to do yet AT LEAST look over how you should do it to make sure there aren't any surprises later on.
I'm not a very experienced programmer myself, however, I have made alot of mistakes that I have tried to learn from. Hopefully this and the original article can save some time!