Software Design (CSC-223 97F)
Outline of Class 22: Coding Practices
- Before today's class, you should have read: Bentley (MPP/3; PP/13),
- Before the next class, you should read: the rest of Winograd.
- Project proposals are due now!
- I've started to read over your comments on the web-based outlines.
If you haven't
filled out the survey, please do so
ASAP. The forms are completely anonymous, so you shouldn't
worry that I'll know who you are.
- Here are some of your comments and my responses; we
won't go over them in class.
- One of you asked me to add a link to the
Java API to every page,
and I've done so (or tried to do so).
- A few of you asked me to get them ready sooner. I'll do my best,
but I will warn you that because this is the first time I'm teaching
this course, I often have to work out my detailed plan the morning
of the course. Next time, it will be better (and I hope to have
them done early for 302).
- A few of you asked for more detail. I worry that if I put in
too many details, then you won't spend time in class thinking about
the details. We're also moving from topics for which detail is
appropriate (facts about a programming language) to topics in which
details may be less appropriate than processes (general concepts).
- A few of you asked me to email you each time I make a change. I
worry that that's so much email that you'll start to ignore messages
from me. I do try to update the news
each time I update a page, and I will email you about updates to
HW assignments (although there will be fewer of those in the second
half of the course).
- One of you was nice enough to worry about how long it takes me to
write them. It takes much less than it used to, now that I use a
special tool for inserting some of the HTML. While it takes awhile
to prepare the outlines, the time is well spent, because it forces
me to think (both about the general structure of each class, and
about the details of what I'm teaching).
- I was sorry to see that a few of you felt that they were useful since
"I get nothing out of lecture". We should probably talk one-on-one
on how both you and I can work to ensure that you can get more out
- A few of you wanted the readings in the outlines. I'll do my best
to add the current and subsequent readings.
- Lea and Ryan are presenting today. They will be discussing
Airbus A320 disaster. A modified
version without the ugly red background is also available.
- I need volunteers for the Friday after break (or, as usual, I will pick them).
- Could those of you who've already made presentations check the
presentation subsite to make
sure that what I have for you is correct? Note that I've made local
copies of your work.
- Earlier, we worked on program verification while wearing our
"mathematician's hat". Now, lets put on our "engineer's hat" and
start thinking about how we'd test our programs and algorithms.
- What are some of the strategies you might use in testing a program or
- It depends on the program or algorithm, but there are a number of
- Use a variety of sizes of inputs
- Empty input
- Size one input
- Powers of two
- Close to powers of two
- Fibonacci numbers (splitting is often hard in the fib numbers)
- Look for a number of different results (successes, failures, different
kinds of successes).
- Pick some small input size, and look at every reasonable variation within
that input size (different kinds of inputs, different orderings, etc.)
- We'll spend some time talking about strategies both for particular
algorithms and for general classes of algorithms and inputs.
- For binary search, Bentley provides a fairly comprehensive test suite.
- Try all input sizes from 0 to 12 or so (I've forgotten the exact number).
- Includes size-zero input.
- Includes size-one input.
- Includes many powers of two (2, 4, 8)
- Includes many variations (primes, composites, etc.)
- For each input size, try
- Every position in the vector (check types of success)
- Something smaller than everything in the list (failure)
- Something larger than everything in the list (failure)
- Between every two positions (other types of failure)
- For sorting routines (or even for other list/array-based routines),
what are some things we might try?
- Different list lengths
- Powers of two
- Things that don't divide evenly (interesting for the O(log_2(n))
- Different orders of inputs
- Sorted in increasing order
- Sorted in decreasing order
- All equal
- Different ranges of values
- Within a small range
- Widely dispersed
- Only one value
- For graph-based routines
- Different sized graphs
- Different layouts/connectivity
- Different weighting on edges
- Within a small range
- Within a large range
- We've already discussed some basic debugging strategies, including
adding output statements, using a visual (or textual) debugger,
and using pre- and post-conditions.
- In general, we've talked about using those in standard runs of the
- However, there are also uses to building a debugging interface to
each program. This interface lets you build and check input data
and to choose what to do with the data.
- Bentley shows a good example in "Confesions of a Coder", column 3
of More Programming Pearls. He also has more good examples
- What operations should your interface include?
- Create an appropriate data set, filling in values
- Set the value of an appropriate element
- Print out the data set, so that you can verify that it
- Print out the values of elements
- Run the algorithm on some subset of the data set
- Note that the design of your algorithms can help make them
more debuggable. For example, an in-place sorting routine that
uses both an array and the indices of a subarray that you want
to sort is much more testable (and flexible)
than one that simply takes an array
as a parameter.
- Let's now step back and think of some other general principles we
might use when building larger programming systems. (Many of these
are taken from Bentley).
- Define your problem. If you don't have a good problem
definitions, it's unlikely that you'll have a good or appropriate
- Prototype. Make simpler/less efficient versions that
let you determine not only whether your algorithm is correct, but
also whether it is appropriate.
- Separate Concerns. Divide your system into independent
components, and make use each works.
- Simplify. Microsoft^(-1). Don't add bells and whistles;
look for "pure" solutions; try solutions you can summarize in a few
- Manage Projects. Keep track of the tasks to be done,
track who currently controls each file, maintain earlier versions,
assign roles, ...
- Estimate (how long it will take, etc.)
- Use a toolbox (and know what's in it and how it works)
- Common algorithms
- Common data structures
- Common algorithm-development techniques
- Common algorithm-analysis techniques
- Refine. When you have something that works, consider how
you could make it even better.