A program that hasn't been adequately tested is worthless. I expect you to choose, and write down, a good selection of test cases (along with the "correct" result of each one) for every function before you write its body. Every program must be accompanied by a session log showing how the program works on test cases. Programs with inadequate or poorly-chosen test cases will lose points.
Every program must be adequately and accurately commented. Ideally, most of your code should be so easy to read that it doesn't need comments, but if there are non-obvious restrictions on the use of a particular variable or function, or non-obvious tricks in your algorithm, explain these.
Having done my share of programming, I know that sometimes you hit a brick wall and cannot get the thing to work for love or money. If this happens, turn in the program together with a description of how the program fails, what you've tried in your attempts to fix it, and how those attempts didn't succeed. You won't get full credit, but if I'm convinced that you're working on it diligently, you'll get some partial credit. Note that "how the program fails" does not mean saying "I got an error message": you need to tell me which error message you got, when you saw it, and what you think the error message means. Similarly, if the program fails by producing wrong answers, you need to tell me when it produces wrong answers (are they all wrong, or just in a few cases?), how they are wrong (e.g. are all the numbers consistently higher than you expected, are they the negatives of the correct answers, or are they all over the place with no apparent pattern?), and your speculations on how such an error might have arisen. I'm requiring all this not because I'm mean and horrible, but because by the time you've written all this down, you may have enough information to actually fix the problem, which is much better than turning it in incomplete.
I also expect you to keep track of the time you spend on various aspects of programming, how many and what kinds of defects you encounter, etc. For each assignment, I'll tell you which tracking information is required. The easiest way to turn in this information is through a collection of on-line PSP forms, which I'll show you how to use. Indeed, I recommend that while you're programming, you have a Web browser running the forms in the background, so you can easily record each defect and each block of time before you forget about it. Failure to turn in this tracking information will lower your grade for that assignment.
Programs will be graded not only on producing correct answers (although that's obviously a requirement), but on how they're written -- the topics discussed in the second half of chapter 1 of the "Walls and Mirrors" textbook. One of these criteria is "modifiability", and to drive home its importance, I'll often change the assignment slightly on the day that it's due. When you read an assignment, you should immediately start thinking "how is Dr. Bloch likely to change this at the last minute?" and write the program in such a way that you can respond to such changes easily. If it takes you more than an hour to handle my last-minute change, you didn't design the program well.