33-debugging.pdf
(
608 KB
)
Pobierz
Mehran Sahami
Handout #33
CS 106A
November 5, 2007
Debugging
Thanks to Eric Roberts and Nick Parlante for portions of this handout.
Much of your time as a computer programmer will likely be spent debugging. This
phenomena is best described by a quotation from one of the first computer pioneers,
Maurice Wilkes:
As soon as we started programming, we found to our surprise that it wasn’t as
easy to get programs right as we had thought. We had to discover debugging. I
can remember the exact instant when I realized that a large part of my life from
then on was going to be spent in finding mistakes in my own programs.
—Maurice Wilkes, 1949
In order to be better prepared to undertake the more complex future debugging that you
will be doing, we aim to give you here both a sense of the philosophy of debugging as
well as to teach you how to use some of the practical tips that make testing and debugging
easier.
The philosophy of debugging
Debugging is one of the most creative and intellectually challenging aspects of
programming. It can also be one of the most frustrating. To a large extent, the problems
that people face debugging programs are not so much technical as they are psychological.
To become successful debuggers, you must learn to think in a different way. There is no
cookbook approach to debugging, although Nick Parlante’s 11 Truths of Debugging
(given below) will probably help. What you need is insight, creativity, logic, and
determination. I've heard that Diet Coke™ helps too, but this may be anecdotal…
As computer scientists, it is important to remember that the programming process leads
you through a series of tasks and roles:
Task
—
Role
Design
—
Architect
Coding
—
Engineer
Testing
—
Vandal
Debugging —
Detective
These roles require you to adopt distinct strategies and goals, and it is often difficult to
shift your perspective from one to another. Although debugging can often be very
difficult, it can be done. It will at times take all of the skill and creativity at your disposal,
but you can succeed if you are methodical and don’t give up on the task.
Debugging is an important skill that you will use every day if you continue in Computer
Science or any related field. Even though it is the final task of those listed above, it is
certainly not the least important. You should always plan ahead and allow sufficient time
for testing and debugging, as it is required if you expect to produce quality software. In
addition, you should make a concentrated effort to develop these skills now, as they will
be even more important as programs become more complicated later in the quarter.
– 2 –
The 11 Truths of Debugging
1.
Intuition and hunches are great—you just have to test them out. When a hunch and a fact
collide, the fact wins. That's life in the city.
2.
Don’t look for complex explanations. Even the simplest omission or typo can lead to very
weird behavior. Everyone is capable producing extremely simple and obvious errors from
time to time. Look at code critically—don’t just sweep your eye over that series of simple
statements assuming that they are too simple to be wrong.
3.
The clue to what is wrong in your code is in the values of your variables and the flow of
control. Try to see what the facts are pointing to. The computer is not trying to mislead
you. Work from the facts.
4.
Be systematic and persistent.
Don’t panic
. The bug is not moving around in your code,
trying to trick or evade you. It is just sitting in one place, doing the wrong thing in the same
way every time.
5.
If you code was working a minute ago, but now it doesn’t—what was the last thing you
changed? This incredibly reliable rule of thumb is the reason your section leader told you
to test your code as you go rather than all at once.
6.
Do not change your code haphazardly trying to track down a bug. This is sort of like a
scientist who changes more than one variable in an experiment at a time. It makes the
observed behavior much more difficult to interpret, and you tend to introduce new bugs.
7.
If you find some wrong code that does not seem to be related to the bug you were tracking,
fix the wrong code anyway. Many times the wrong code was related to or obscured the bug
in a way you had not imagined.
8.
You should be able to explain in Sherlock Holmes style the series of facts, tests, and
deductions that led you to find a bug. Alternately, if you have a bug but can’t pinpoint it,
then you should be able to give an argument to a critical third party detailing why each one
of your functions cannot contain the bug. One of these arguments will contain a flaw since
one of your functions does in fact contain a bug. Trying to construct the arguments may
help you to see the flaw.
9.
Be critical of your beliefs about your code. It’s almost impossible to see a bug in a function
when your instinct is that the function is innocent. Only when the facts have proven
without question that the function is not the source of the problem should you assume it to
be correct.
10.
Although you need to be systematic, there is still an enormous amount of room for beliefs,
hunches, guesses, etc. Use your intuition about where the bug probably is to direct the
order that you check things in your systematic search. Check the functions you suspect the
most first. Good instincts will come with experience.
11.
Debugging depends on an objective and reasoned approach. It depends on overall
perspective and understanding of the workings of your code.
Debugging
code is more
mentally demanding than
writing
code. The longer you try to track down a bug without
success, the less perspective you tend to have. Realize when you have lost the perspective
on your code to debug. Take a break. Get some sleep. You cannot debug when you are not
seeing things clearly. Many times a programmer can spend hours late at night hunting for a
bug only to finally give up at 4:00
A.M.
The next day, they find the bug in 10 minutes. What
allowed them to find the bug the next day so quickly? Maybe they just needed some sleep
and time for perspective. Or maybe their subconscious figured it out while they were asleep.
In any case, the ―go do something else for a while, come back, and find the bug
immediately‖ scenario happens too often to be an accident.
— Nick Parlante, Stanford University
– 3 –
Using an online debugger
Because debugging is a difficult but nonetheless critical task, it is important to learn the
tricks of the trade. The most important of these tricks is to get the computer to show you
what it’s doing, which is the key to debugging. The computer, after all, is there in front
of you. You can watch it work. You can’t ask the computer why it isn’t working, but
you can have it show you its work as it goes. Modern programming environments like
Eclipse come equipped with a
debugger,
which is a special facility for monitoring a
program as it runs. By using the Eclipse debugger, for example, you can step through the
operation of your program and watch it work. Using the debugger helps you build up a
good sense of what your program is doing, and often points the way to the mistake.
To illustrate the operation of the Eclipse debugger in as concrete a way as possible, let's
look at how we might us the debugger to find bugs in the
Roulette.java
program
shown in Figure 2 below. As the bug icons indicate, the program is buggy. As a
programmer, it is your job to figure out why. The remainder of this handout describes the
techniques you might use to look for bugs with the help of the Eclipse debugger.
– 4 –
Figure 2. Buggy program intended to play a simplified form of roulette
/*
* File: Roulette.java
* -------------------
* This program simulates a small part of the casino game of
* roulette.
*/
import acm.program.*;
import acm.util.*;
public class Roulette extends ConsoleProgram {
/** Amount of cash with which the player starts */
private static final int STARTING_MONEY = 100;
/** Amount wagered in each game */
private static final int WAGER_AMOUNT = 10;
/** Runs the program */
public void run() {
giveInstructions();
playRoulette();
}
/**
* Plays roulette until the user runs out of money.
*/
private void playRoulette() {
int money = STARTING_MONEY;
while (money > 0) {
println("You now have $" + money + ".");
String bet = readLine("Enter betting category: ");
int outcome = spinRouletteWheel();
if (isWinningCategory(outcome, bet)) {
println("That number is " + bet + " so you win.");
money += WAGER_AMOUNT;
} else {
println("That number is not " + bet + " so you lose.");
money -= WAGER_AMOUNT;
}
}
println("You ran out of money.");
}
– 5 –
Figure 2. Buggy program intended to play a simplified form of roulette (continued)
/**
* Simulates the spinning of the roulette wheel. The method
* returns the number of the slot into which the ball fell.
*/
private int spinRouletteWheel() {
println("The ball lands in " + rgen.nextInt(0, 36) + ".");
return rgen.nextInt(0, 36);
}
/*
* Returns true if the outcome matches the category specified
* by bet. If the player chooses an illegal betting
* category, this function always returns false.
*/
private boolean isWinningCategory(int outcome, String bet) {
if (bet == "odd") {
return outcome % 2 == 1;
} else if (bet == "even") {
return (outcome % 2 == 0);
} else if (bet == "low") {
return (1 <= outcome && outcome <= 18);
} else if (bet == "high") {
return (19 <= outcome && outcome <= 36);
} else {
return (false);
}
}
/**
* Welcomes the player to the game and gives instructions on
* the rules of roulette.
*/
private void giveInstructions() {
println("Welcome to the roulette table!");
println("Roulette is played with a large wheel divided into");
println("compartments numbered from 0 to 36. Each player");
println("places bets on a playing field marked with the");
println("numbers and various categories. In this game,");
println("the only legal bets are the following categories:");
println("odd, even, low, or high. Note that 0 is not in any");
println("category. After the bet is placed, the wheel is");
println("spun, and a marble is dropped inside, which bounces");
println("around until it lands in a compartment. If the");
println("compartment matches the betting category you chose,");
println("you win back your wager plus an equal amount. If");
println("not, you lose your wager.");
}
/* Private instance variables */
private RandomGenerator rgen = new RandomGenerator();
}
Plik z chomika:
m_r_k
Inne pliki z tego folderu:
stanford_eclipse32_mac.zip
(128583 KB)
stanford_eclipse32_windows.zip
(131096 KB)
jre-6u2-windows-i586-p.zip
(13189 KB)
03-course-placement.pdf
(315 KB)
01-general-information.pdf
(75 KB)
Inne foldery tego chomika:
Zgłoś jeśli
naruszono regulamin