The assignments do not provide complete detail about what you must implement, because this is usually not provided in real-world projects.  All the projects are about teamwork and report-writing, in addition to programming languages.  You will never have a job outside UCSD that is about programming languages only. 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 are 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.

The assignments say, "Your code must follow all 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 means 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 the written document. This must be in correct English with simple, clear formatting. You must read, edit, and revise your own work until it is high-quality.

We certainly don't want padding in the reports. If you can address all the necessary issues in reasonable detail in less than five pages, that is fine. We won't take points off just because a paper is too short.  Please do not make your paper longer than six pages! In technical reports, conciseness is a virtue.

The point of the projects is not error-checking.  Here are some general guidelines for error-checking, for this assignment and all others.
(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.  This is an upper-division course for computer science majors. 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.

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