Department of Computer Science and Engineering CSE 92
University of California at San Diego Spring 2005

General Notes on Programming Projects


Most assignments do not provide complete detail about what you must implement, because this is usually not provided in real-world projects.  Similarly, most projects are about teamwork and report-writing, in addition to programming.  You will never have a job outside UCSD that is about programming exclusively.  Jobs will always require you to combine your knowledge and skills from several related areas.

If you are not sure about a requirement that will take a lot of effort, do ask.  However, note that "requirements" are very different from "design."  Requirements are what the user wants, while design is how you organize your software to satisfy the requirements.  Design is your responsibility, and you should expect to be graded on the quality of your design.  If sample inputs or outputs are not provided, then you should invent your own test cases using your knowledge and intelligence.

Your code must always follow the principles of good software engineering that you have learned in other courses.  No particular style is required in design or coding, but we do want to see quality, not just output correctness.  We are flexible in grading but it is always your responsibility to make your software clear and simple and reliable.  Quality includes clear and reasonably simple design and coding, with good commenting and indentation.  You must tidy up your software before submitting it.  The same is true for any written documents.  These must be in correct English with simple, clear formatting.  You must read, edit, and revise your own work yourself until it is high-quality.  We certainly never want padding in written documentst.  In technical reports, conciseness is a virtue.

The point of most class projects is not error-checking.  In this spirit, here are some general guidelines for error-checking:

(1) Do error-checking, but don't do unnecessary error-checking.
(2) Try to catch errors as early as possible.
(3) When you do catch an error, don't try to fix it unless the fix is *always* correct.
(4) Don't let error-checking slow down the code significantly, when no errors are present.
(5) Don't let error-checking make the code less clear, for the case where no errors are present.
(6) Do use the mechanisms provided by your programming language (such as exception-handling) to cope with errors.

You must decide yourself exactly how your program handles errors, using these principles as a basis.  As for other issues, we will be flexible in grading but we expect high quality.

About debugging: Most compilers for most languages generate syntax error messages that are hard to understand.  Often the actual mistake is nearby, but not exactly where the error message appears.  You must use your intelligence to understand error messages.  Lecture time is a valuable resource that we spend on topics that are deeper than error messages.  Suppose you have a syntax error, or any other sort of bug, that is difficult to find and fix. A good strategy is to read your code carefully and clean it up.  Make the indentation perfect and simplify anything else that is more complicated than necessary. Remove everything that is not necessary. Often you will find that the mysterious bug has gone away.  Even if not, you may get a more understandable error message.

In other words, often the way to solve a problem is not to add something new; it is to remove something old that is wrong or unnecessary.