[/caption]Debugging is a very different task from coding and it benefits from a different mindset. Finding bugs can take time and can involve a lot of trial, error and testing of different thoughts as to what might be going wrong, because there are lots of places in code where errors can hide. This means you need to be patient. Accept that sometimes it will take a lot of painstaking effort to make something work properly, and remind yourself that it's worth it because you want to be able to trust the results your code is giving you. It's very tempting to rush through debugging, but sometimes you just need to use a slow-and-steady approach. And remember, getting frustrated doesn't make bugs easier to see (quite the opposite, in fact), so try to stay calm. Deep breaths...
Assumption: the mother of the screw-up
One very important skill to develop when debugging is that of not making assumptions. We call it a skill because it's surprisingly easy to make assumptions if you're not careful. What we're talking about are thoughts along the line of "this piece of code returns an integer, so the next piece of code must work fine.". Really? Are you sure? Presumably as you wrote the code, you thought you were writing the correct thing. And yet now your code doesn't work. So you already know that somewhere in your code, there is a bug where you'd assumed there wasn't one. Maybe in more than one place. This means that you need to test all your assumptions, find the one/s that are wrong and then fix them.
There is an art to this and it's something you'll become better at as you get more experienced. Often, a given language or type of statement will have certain ways in which they're most likely to be going wrong and this can give you a good idea where to look first for particular bugs. But it won't exclude other possibilities, so you really have to approach debugging by being willing to believe that any part of your code might be broken. Especially the parts that are "definitely fine".
This can often happen in case-sensitive languages where "a" is different from "A". For example:
massInKilos = 2.5
massInkilos *= 2
Not very easy to spot, right? (the "k" is in a different case in the two lines)
Elementary, my dear Watson
Debugging is a bit like detective work in that you'll find yourself assembling sets of facts, often as the results of tests, that tell you how your code behaves in certain situations. And on the basis of this information, plus looking at the code itself, you'll try to figure out what might be going wrong. This is another reason why being methodical is useful; every new piece of information you gather about your code is something new that might help you spot what's going wrong.
This gathering of new information can be very important. All bugs are easy to fix if you know enough about them, so it might be that the easiest way for you to fix your code is to keep finding out more until suddenly it's obvious what's going wrong (and how to fix it). Indeed, a lot of the other aspects of Testing and Debugging are aimed principally at finding out more information so that you an figure out what the bugs are in your code.
They're all against me!
Finally, when you've been working for hours and getting nowhere, it can help to remind yourself that code is deterministic, even if it doesn't seem like it (this can even be true of random number generators, if you fix the input seed). If you've spotted a problem, there is a reason, you just have to gather enough information to figure out what it is. Poker players would call this mental state Tilt, which is where you've slipped into a bad frame of mind for the task at hand. Don't play when you're tilted; take a break and refresh your brain.
And above all, remember to stay calm! Debugging can be frustrating at times, so you need to try to stay in a good frame of mind and approach it in the right way. If you do this, you'll find those bugs a lot more quickly and can get onto something more interesting!
No comments:
Post a Comment