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?

1. All your source files, both .h and .cpp, as appropriate.

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

Start early, stay in touch, and have fun.