1. Solve each problem on your own.
2. All assignments must be neat.
3. Pages must be stapled. Period.
4. Include name and date and section.
5. Almost all variables and procedures 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 substitute.
6. You must demonstrate the effectiveness of your code by showing a thorough suite of test cases that rigorously exercises your code. Do not show us a random selection of data; rather choose data that demonstrate that your code works for simple and complex data, and data at the extremes (empty list, 0 1, nested lists, etc.). We will not give you test sets for most problems, but will expect your code to work for any test sets we write. If you have a question about testing, ask well before the due date!
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 and actual code behavior will result in a zero, and will 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 as homework in this course!).

Remember, we comment our code as we write it. (Most) comments are not afterthoughts, but rather part of the process of writing good code. The block comment at the top of each function/procedure needs to explain what the function does, what arguments it expects, and what value it returns. In the case of side effects (rare), these should be documented as well. The purpose of the comment is to let a programmer know when it is appropriate to use this function - i.e., it documents a function's purpose.

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.

I will talk about style in class; the book uses fairly good style (except for commenting!). If you model your code on the code from class or the text, that should take care of all your style needs (with the exception of comments - because in class I am speaking to you about what I am coding while I'm coding, as is the text).

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

10% naming
100% formatting
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% testing
20% error checking
10% stapled

Clearly these 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 eighty 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.