Transcript Download presentation source

CS100A Lecture 22 17 November 1998
•Prelim 3
Tonight, 17 November, 7:30--9PM
Uris Auditorium
•An extra-credit assignment
•Debugging programs
CS100A, Lecture 22, 17
November 1998
1
Extra-Credit Assignment
Here’s a chance to design part of a program yourself and
get extra credit for it.
You can do this assignment in groups of 1 or 2 people.
Extra credit will work like this. We will assign class
grades, without taking this assignment into account. Then,
for each student who did this assignment, we will see
whether this assignment would put them into a higher
grade category (and act accordingly). The assignment will
be worth roughly about 25% of prelim2.
Assignment: Extend the Checkers Program so that it
allows several jumps in a row.
Timetable:
0. In lecture, 31 November, hand in a short specification
that describes how the user will know they can make
another jump and how they either make the jump or
decline to do so. (Declining to do so could be indicated,
for example, by the other player moving.) Try to keep this
as simple as possible. This will require some changes to
what appears on the GUI.
1. We will respond quickly with a critique (pick up in
Carpenter), after which you can start designing and coding
the change.
CS100A, Lecture 22, 17
November 1998
2
Extra-credit Assignment
2. Hand in a copy of your completed assignment --class
Checkers only-- TOGETHER WITH A FLOPPY DISK
THAT HAS THE COMPLETED PROJECT, on or
before 10 December, in Carpenter or in Upson 4115.
Two points on the design of this extension:
•1. The GUI should indicate that a player can make
another jump ONLYafter a jump has been made and if
another jump is actually possible. Thus, your code has to
check after a jump whether another jump is possible.
•2. You may do whatever you want concerning how a
player is told that another jump is possible. We think that
all is required is to change the strings in Labels
whoPlays, nextTask, and nextTask1.
Note: For those of you who want to work on this
assignment over Thanksgiving: Hand in the specification
in lecture on Tuesday 24 November; we will have a
critique ready for you by Wednesday morning.
Note: You can use our correct class Checkers (see the
CS100 web site). You may want to use it rather than
yours, for you will have problems if yours has mistakes
in it.
CS100A, Lecture 22, 17
November 1998
3
DEBUGGING
Even the best of programmers make mistakes.
So all programs have to be debugged.
Guidelines for making debugging easier
1. Use precise specifications on methods.
2. Write precise definitions of variables, before you write
code that refers to them. And when writing code that
refers to them, look often at the definitions.
Here’s a simple view of programming:
Define your variables precisely, and then
write your code to make progress to the desired
goal, but keeping the definitions true.
3. Use good indentation practices
CS100A, Lecture 22, 17
November 1998
4
Guidelines for making debugging easier (continued)
4. Do your programming incrementally. Write some
code, check it out, write some code, check it out ...
5. Keep comments consistent with the code. For
example, when you change the body of a method to
make it do something different, change the specification
of the method as well.
6. Make sure a method is completely correct before
trying to debug code that uses it.
7. When debugging, the worst thing to do is to make
change after change in a haphazard manner with the
hope that one of them will correct the error. Changing
without understanding is ludicrous. Don’t do it.
CS100A, Lecture 22, 17
November 1998
5
Two methods of analyzing execution of a
program to find an error in it
•1. Use the debugger. The debugger lets you execute the
program one statement at a time, looking at the values of
variables as the statements are executed. The debugger in
Codewarrior is not yet debugged itself for us to use this
method in a real program --at least in our experience.
Therefore, we will study the second method. However, if
the debugger is well designed and working properly, it
can be far more effective in the hands of a professional
than can the second method.
•2. Insert println statements in judicious places within
the program, execute the program, and analyze the
output. Disadvantage of this technique, you are continually inserting and deleting println statements.
In this lecture, we illustrate the use of method 2 on some
examples from the checkers program.
You think you have trouble debugging! [Give the “safe
torpedo” anecdote.]
CS100A, Lecture 22, 17
November 1998
6
Using method toString. Debugging is often easier if
each class has method toString; it can be used to print out
a description of any instance of the class. For example, a
description of checkers square (2,3) can be printed using
System.out.println(board[2][3]);
Determining placement of println statements is
difficult. Too many printlns means too much output and
output that is hard to decipher. Too few printlns, and at
the wrong places, will be of little help.
Don’t expect one set of printlns to find your error. Like
in a treasure hunt, you may look in many wrong places
before finding the error.
Use binary search. You can sometimes hone in on the
error using a binary search. If you believe that any of
statements S1, S2, …, Sn may contain the error, then try
to choose a place to put the println statements that, no
matter what the output is, will allow you to eliminate half
of them from consideration.
CS100A, Lecture 22, 17
November 1998
7