Some simple but useful debugging tips
Blitz3D Forums/Blitz3D Tutorials/Some simple but useful debugging tips
| ||
| It's actually an articly directed at those writing scripts for neverwinter nights, but the tips are just as applicable to Blitz. http://nwvault.ign.com/Files/other/data/1043636139500.shtml |
| ||
| 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! |
| ||
| Without reading the article here's a couple of debug methods I use: Messages: Put messages in your code. If you don't know where things are going wrong create a breakpoint function. Something like; function BreakPoint(message$) cls print message waitkey end function This if you really can't work out where your code is going wrong you can throw messages in all over your code and see at what point it breaks. Visible Debug Stuff: Create a whole debug library that allows you to draw lines, messages, circles, whatever, the alien breed has a good example of a debug library (even though I say so myself!) which allows you to if you have debug mode (global variable) switched on various debug stuff gets added to the screen, this way you can sort out what everything is doing and maybe work out why your AI is going mental. The debug stuff is then drawn after everything else so it's always visible. Indent: If you don't indent your code you're a fool! So many "This bloody thing won't compile" problems are due to a stray endif or next. Indent your code and it is clear where your code is going wrong. Complex If statements: If a>0 and b<0 and b>50 or c>20 and d<9 etc etc etc then... These go wrong very often because of the way a particular language vaidates this stuff. Quite frankly do nested ifs, I've speed checked this stuff and there's shag all in it and it makes your code much more readable. Also, test your 'if' in a standalone piece of code to see if it does what you expect it to do. Comment: I know it's a pain but do it. |
| ||
| Also, watch your mix-and-match of variables. If you need a floating point result, make sure your elements doing the math aren't integers, or you will get ugly surprises for your results. Where x= an integer (not floating point): x=3.0/4.0 gives an answer of 1, not .75 and x=3/4 gives an answer of 0 (zero), not .75 and x#=3/4 gives 0.0 for an answer, not .75 |
| ||
| As Rob Farlay say's its the best way to debug your program. I program a lot. Mostly for simple programs that i want to make some things simpeler. If i make a program i use always a couple of steps before i start to write the program. 1. I write down the idea on paper. And make a screen layout of the screen i think i wil needed. 2. Stil on paper is start in global steps what the program must do. Then i start to devide the steps in smaller steps. I do this untile i think all steps are smal enough to start programmingen. 3. i try to find out where i can use function or subroutine. A big number of steps i have made go under that. 4. i have a library of smal functions and subroutines. dig in there and look at the disciption of how the function supposed to work. Make a new project folder and copied all the files i needed to there. 5. Then i start to make the program first by only putting in remarks. And a global variable called Program_Step$. In all the remarks i put in the step desciption in Program_Step$. 6. Now i start to make the source code. Even if the lines are inserted many time i add a remark at the end line 7. Save the source code on a backup folder. if i make a ugly mistake i can always take a step back. 8.if the program runs first time the Global debug is on true so the function wil call almost on every step. Even te debug log turns on. This all gives me a good idea of how the program supposed to work. and there is always a little mistake. because of all the debug info its easy to find and correct them. Its look like that it is a lot of work. But remenber that even great programmers work first on paper before they start programming. After programming thats 40% comes 60% debugging and testing. Example. I had made a program that puts a puzzle together. If the player does it good he goes to the next level. What i not calculated in the program was that the player not even come trough level 1. So his score would be zero. My program was already working for a couple of mounths. And them somebody come and make no score. The program crashed. NO GOOD. But because i had break down my program i little pieces and al the step was a single program block. it was easy to repair that. Because of the many remarks it was easy to pic u the program good. (If you see your program source code not for a long time. Then it is hard to get in the program if there is no remarks.) I hoop i give you a tip of making and debugging you program. |
   |