CS 117 Final Project
Due 5:00 PM Wednesday, 3/14/01
You have by now produced a preliminary project proposal and a
more detailed proposal. This document describes the final "deliverables"--that
is, the things you need to hand in as your finished project on or
before 3/14.
What to Hand In, When, and How?
By 5:00 PM, Wednesday, March 14, submit the following via HSP.
- All your source files, both .h and .cpp, as appropriate.
- A file named finalReadMe.txt, which should include a
list of the source files in your project, a description of
what your program does, and a description of the status of
your program (what works, what doesn't, lingering bugs, etc.).
An updated version of your second proposal might serve nicely for most
of finalReadMe.txt.
Grading Criteria
- Does your program compile? I can't test it (and thus can't grade it)
if it doesn't compile. Note that many people add their comments
only after they have completed their coding. This is a very bad idea
from the software design point of view, but it is also a great
way to accidentally introduce syntax errors. Always compile and
run your program immediately before submitting it.
- Does it work? Correctness is the most important thing, though
by no means the only thing. Your program should work. If it doesn't
do exactly what it was intended to do, you should provide a
discussion of your program's limitations in your documentation.
- Is your program well organized?
Well-designed function interfaces, good use of classes where
appropriate, and a main program that reads like an outline of the
program as a whole contribute to readable, debuggable, and maintainable
programs.
- Is your program well documented? Your code is a
piece of writing directed to two audiences--compilers and human readers.
You need to make the code readable to both audiences,
and clear commenting is an essential part of what you do for your
human readers.
- Is your program written with good style? Descriptive
variable/function/parameter names, consistent indentation and
placement of braces, and appropriate comments are the fundamentals
of good coding style.
- Sometimes, efficiency is relevant. For example, a bad
search algorithm with a big dictionary can lead to
unreasonably long run times for a spell-checker.
- If everything above is done well, an ambitious program
may get a better grade than a less ambitious one. For example,
a spell-checker that can handle an arbitrarily large dictionary
is more impressive than one that can handle only 200-word dictionaries.
On the other hand, a 200-word spell-checker that is works correctly and is
well organized, designed, and documented is much better than a
buggy, messy, poorly commented spell-checker that can use a big dictionary.
That's all
If you have questions, please let me know.
Start early, stay in touch, and have fun.
Jeff Ondich,
Department of Mathematics and Computer Science,
Carleton College, Northfield, MN
55057, (507) 646-4364,
jondich@carleton.edu