Assignment Standards

These standards supercede the standards in the lab manual where they overlap. The lab manual is the default resource for any issues not covered here.

Requirements

1. Solve each assigned problem on your own.
2. All assignments must be neat.
3. All pages must be stapled. Period.
4. Include name, date, section, and filename. Also, include a general statement about the program's functionality.
5. Almost all variables and functions must have meaningful names. There are a few exceptions to this that will be discussed in class. If you don't like typing long names, type short names, then go back and use your editor to substitute (M-% in emacs).
6. All code must be rigorously tested by you. Use your best judgment in determining how to test. We will give you test sets for most problems but will also expect your code to work for any test sets we write. If you have a question about testing, ask well before the due date! You do not need to handle incorrect input unless we specify that you must do so.
7. Any handwriting must be very clear. Any fonts used must be large enough to be easily read.
8. If you are modifying existing code, place large comment boxes before and after changes you make so that the grader can see the changes without hunting for them. Better yet, add color to your homework with a red pen or a highlighter to make it even easier.
9. Any discrepancy between test results you show us and your actual code behavior will result in a zero and may be reported as a cheating incident through the proper University channels.
10. Use procedural decomposition to break your task into small, manageable procedures that accomplish sensible subsets of tasks. If you find yourself doing lots of itemizing of cases, try to think of a different way to tackle the problem. (There are times when only a big list of conditions/cases will do, but these cases are rather rare, and we don't usually assign them in this course!).
11. Submitted programs must compile. If they don't, we will take at least 40% off your grade. Program in pieces so that you can easily find errors.

Many students consider the finishing points of programming to be a trivial matter, but they are very important to the person who is grading your assignment, and to your eventual employer (even if that's you!). Good coding habits cannot be "switched on" when you are hired by a company; it takes effort to learn these programming skills, just as it takes effort to learn the effective use of a given language.

Professor Harvey will talk about style in class constantly; the book uses good style. If you model your code on the code from class or the text, that should take of all your style needs (with the possible exception of comments - because in class Professor Harvey speaks to you about the coding, as is the text).

Accordingly, assignments can lose the following percentages for bad programming style:

• 10% naming
• 100% formatting/indenting
• 20% comments
• 20% parameter descriptions and/or data examples (if not defined in assignment)
• 20% modular structure

and the following deductions may be taken for submission problems:

• 20% missing or poor testing
• 20% error checking
• 10% stapled

Clearly the deduction add up to more than 100 percent. Like most things in life, there are many more ways to do something wrong than to do it right. You will not receive a negative score for a problem.

Most of these things are critical to the job of the TA grading your assignments. Take testing, for example. If you do not include proper testing, your TA must work harder to determine if your assignment is correct, and that isn't fair to a TA grading many assignments. Also, correct code is easier to grade than broken code; if your code doesn't work quite right, SHOW the test that it can't do and circle it, and we'll at least know that you knew something was not quite right. :)

Particularly egregious violations of any style or submission parameter may result in a larger impact on your grade, and not all transgressions will merit the full penalty.