Page 4 —
Fixing Bugs
Finding a bug, though sometimes difficult, is only the first step. Next you
have to get rid of it. Here are a few things you should do as you crush
those bugs:
Copy your program first.
Some bugs are really
hard to get rid of. In fact, sometimes a little
bug can drive you so crazy
that, in the process of eradicating it, you destroy your entire program.
Saving your program before you start debugging is the best way to ensure
that a bug doesn't get the best of you.
Fix one bug at a
time.
If you know about several bugs, fix each one and test your
fix
before you move on to the next bug. Fixing a lot of bugs all at once
without checking your work is just an invitation for even more
bugs.
Beware of voodoo coding.
Sometimes you know a bug
exists, but you don't really know
why. Lets say you have a variable
called "index," and for
some reason "index" is always one less than you
think it should be. You can do one of two things: sit there for a while and
figure out why it's coming up short or just shrug,
add one to index
before using it, and move on. The latter method is
called voodoo
programming. When you start thinking "What the hell —
why is index two
instead of three? Well ... I'll just make it work for now and
fix it later,"
you're slapping a Band-Aid on a potentially serious wound.
Voodoo programming may work in the short term, but you're
looking at long-term doom — if you don't understand your code enough to
really get rid of a bug, that bug will come back to haunt you. It will
either return in the form of yet another weird error that you can't figure
out, or it'll make your
code extremely hard to understand for the
next poor soul cursed to look at it.
Look for similar
bugs.
In some ways, the ability to cut and paste code is the worst
thing
for programmers. Often, you'll write some JavaScript in
one
function and then cut and paste it into another function. And if the first function had a problem, you now have problems in two
functions. I'm not saying you shouldn't cut and paste code. But bugs have a way of multiplying, so if you find one, you should look
for others that are
similar. (Or just make sure something works before you
start creating multiple versions of it.) Misspelled variable names are the
kind of thing that crops up several times in one JavaScript — misspell
the_name as
teh_name in one place, chances are you've
done it someplace else.
If all else fails ...
If you're
sitting there, staring at a bug, and you just can't
figure out what's
going on (or if you can't even
find the bug in the first place, but you
know it's there because your program isn't working right), the best thing
to do is walk away from your computer. Go read a book, take a stroll
around the corner, get a tasty beverage — do something, anything, but
don't think about the program or the problem. This technique is called
"incubation" in some circles, and it works amazingly well.
After you've
had a little break and relaxed, try finding the bug
again. You'll
approach the problem with a refreshed vision that's often quite
illuminating. Incubation works because it breaks you out of a (dare I say
it?) dysfunctional mindset. If you follow a wrong path for too long, you
sometimes get stuck with no room in which to turn around. The best thing to do when
this happens is find a way to start down a new path. I know it's
touchy-feely, but it works. Really!
And if that
doesn't work ...
Ask someone for help. Sometimes you wear such a rut in
your problem with repetitious thought patterns, only someone with a
fresh eye can see the hole in your logic. In structured coding
environments, programmers periodically review one another's code. This is
appropriately named "code review," and it
not only helps iron out bugs, it
also results in better code. Don't
be afraid to show other people your
JavaScripts. It makes you a better
JavaScripter.
But the
absolute best way to eradicate bugs is ...
