CS100A%20%20Lecture%2022%20%2017%20November%201998

1

• CS100A Lecture 22 17 November 1998
• Prelim 3
• Tonight, 17 November, 730--9PM
• Uris Auditorium
• An extra-credit assignment
• Debugging programs

2
Extra-Credit Assignment Heres 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.
3

• 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.

4
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. Heres 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
5
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. Dont do it.
6

• 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 con-tinually 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.

7

• 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(board23)
• 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.
• Dont 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.