Debugging Tips

You have a BUG in your program!

Tip Zero: don't panic! keep a positive attitude "you CAN fix this!" but it helps if you've given yourself enough TIME so you're not pressured by deadlines!
Tip First: are you sure it's really a bug? maybe the user just misunderstood what the behavior of the program was supposed to be - read the manual. "It's not a bug, it's a feature!"
Tip Second: does the program translate properly? = does it have syntax errors? It's hard to tell what it DOES until you get it to DO something. Fix those - look at examples in the book, try to understand the error message from the IDE, ask for help.
In most languages, you may get "spurious" error messages. These happen when the translator gets confused by an error and starts spewing out lots and lots. Just fix the first one and try again. Many of those will go away!
Tip Third: once it translates ok and does something, then how do you know there's a bug? you put some input in and see what comes out. It either is right, or it isn't. Document what you did in either case - write down your input and output!
- If it is correct, then see what part of the code was tested by that input/output and mark it on the source code "tested". Then try another input and see if the output is right.
  Repeat until you have checked off all the code in the program. This won't guarantee you find all the bugs - it's easy to miss combinations of code - but at least it's systematic.
- If the output is not correct, can you tell just why it isn't? if the values are coming out but are not right, look first at the output statement itself - are you printing out the right variable? in the right format?
  - If no, try changing that and run again.
  - If yes, then the value of the variable is incorrect. Why? Where does that variable get changed? What does it depend on? user input ? other variables? Work backwards. Check your operators - did you say + when you meant * ? Check your types - did you do integer arithmetic when you meant to do floating point? Did it get initialized when you thought it did, with the value you thought it got? This is where tracing can help!
- If the lines of output are not even coming out when you expected, then the output statements are not getting executed. Why? are they part of a function that didn't get called when you thought it would? are they in a loop body that didn't get executed? are they part of an if statement whose condition wasn't true when you thought it should be?
  - Why would a loop not get executed? the condition at the top is mostly to blame - are you sure it's ever true?
  - Why would an if's statements not get done? again, look at the condition - it is the key - is it always true? always false?
  - Check "and" operators and "or" operators - have you switched them?
  - Check "==" and "=" operators - did you use one when you meant the other?
  - Check parameters and return values - have you used the one you need?
- You don't have to wait until the whole program is written to test it, either. Sometimes it works better to write the program incrementally. Write one part and see if it works. Test it thoroughly. Then add another piece to it and test those together.
- "The sooner you find a bug, the cheaper it is to fix!" (Quote from a professional software tester) Finding a bug in the design phase is pretty easy to fix; just change your design document. Not finding a bug until you're about to submit it is painful! You will have to go through all your testing again after you fix it.

If you find a bug,

First: fix it! don't ignore it! don't think "well, one bug isn't too bad" - it may be concealing others
Second: go back and test the code you had already tested - fixing one bug may cause (or uncover) another in places you didn't expect! "Regression testing"

Environment tips

USE the debugger that is available in your environment. It is NOT an admission of "defeat" to turn to the debugging tool! EVERY programmer has had bugs! Use the tool - that's what it's there for! You CAN just add output statements at various locations in your program, translate and run the program again - check the outputs, etc., find the bug. But then you have to take the debugging output statements OUT again, and as soon as you do, it seems you need them again. The integrated debugger can show you a lot of information without having to change the program at all. You can see variable values, you can see what statements get executed and when. Use the debugging tool enough to be comfortable with it and it will repay your investment many times over.
If you change your program source, make sure in your environment that you translate your program again. Some environments do NOT automatically retranslate after changes! You may be running an old executable!
Keep backups and old versions of your source code, so you can go back to them if you need to. Make a backup copy before making any major changes in your code! you can get rid of them later if you want to, but you may be very glad you have them. It makes you a little freer to try something totally different if you know you can go back to the previous version if you have to.

Keep a debugging log or journal

Every time you figure out a bug, especially a tough one, write it down! Write down when, where, what, how you fixed it. Record any resources you used - books, people, web sites.
This may take a little time, but it is a great learning tool. You have run into a tough bug? go back and flip through the journal; maybe you've run into something like it before.
Even if you're not programming something, go look through the journal for patterns - do you make the same mistake a lot? like being off by one in counter-controlled loops? or forgetting to initialize variables? You can be on the lookout for those when you program!

General advice:

Again, give yourself TIME to do this - debugging will take MORE time if you try to hurry. You run into a tough bug? look at everything you can about the problem, and then let it rest a while. Your subconscious can come up with new angles, sometimes a solution! if you let it work a while. Go take a walk, do some other homework, go clean something.

Another tactic - take time to write down exactly what the bug seems to be doing - as clearly as you can, as precisely as you can. Or talk it out to someone who will listen (not recommended to be a student in the same class!) - talk to your cat! talk to Albert Einstein! A lot of times as soon as a student tells me what their problem is, they suddenly say "oh! never mind, I see it!"

Try to focus on one bug at a time. Sometimes you can see evidence of more than one bug, and sometimes you can see the solutions to them all at once, or the solution to one is the solution to the other too. But a lot of times, you need to fix one bug before you can understand the other one. And as stated above, fixing one bug can uncover more.

DON'T just "throw some code at it"! People do try random changes "maybe it should be 1 instead of 0" "maybe it should be less than instead of greater than"... Think first! The odds of fixing a bug correctly by just changing something without understanding what you're doing are very low!

Sometimes the only solution to a bug is to toss out what you have and start over. If you peck away at code that isn't working and is badly designed, you WILL end up rewriting it - either with a fresh start, or a piece at a time. The experience you gained in the first attempt may be the difference that makes the second one work.