There are very few circumstances which will convince me to extend the due date. In particular, minor system crashes and data loss are routine facts of life and should be allowed for.
Except as noted below, I will accept assignments up to one class day late, with a 25% penalty on those parts that are late. Anything submitted after this does not count. For example, a 100-point assignment that was turned in half on the due date and half at the next class meeting would receive a penalty of half of 25%. If it was otherwise completely correct, it would get an 87. I may not accept late submissions if they are not turned in by the beginning of class. Late submissions may not be graded as promptly as work turned in on time.
I will not accept late submissions for the last assigment of a semster unless I explicitly state otherwise.
It never hurts to turn in an assignment on the due date, even if it isn't correct. In general the grade that you get will be the better of the grade for the version turned in on time (partial credit with no penalty applied) and the grade for the late version (with the penalty applied). If I return the earlier version on the day that you turn in a later version, you need to resubmit the hard copy of the earlier version on that day -- I will need it to complete the grading.
If an assignment has the form of a problem set, your submission is to be a hard (printed or handwritten) copy. The purpose of the hard copy is to serve as a permanent record of deductions, my comments, and the assignment grade. A small penalty (no more than 5% of the maximum grade) will apply if you turn in only a soft copy. The second, third, and fourth paragraphs in the following section (on programming assignments) also apply to problem sets.
The purpose of the hard copy is to serve as a permanent record of deductions, my comments, and the assignment grade. The hard copy is the official version; it is your responsiblity to make sure that the soft copy matches the hard copy. Small penalties (no more than 5% of the maximum grade) will apply in cases of mismatch, if you turn in no hard copy, or if you don't use email to turn in your soft copy. These small penalties may apply if your soft copy has excess files, or if your email submission doesn't meet the specifications of the next paragraph.
Make sure that any email submission is identified in the subject line as a homework submission, with the class number and assignment number. You needn't include the section number. Please identify your submission in the subject line as a late one if that is the case. Otherwise, if your submission is a revision of an earlier submission, please use the word "revised" in your subject line. Note that a submission can be both late and revised.
If you email me a question about an assignment, make sure that the subject line of your message does not suggest that the message is a submission of an assignment. If it does, I may not answer it in time. For the same reason, please do not include any questions with a submission.
If your solution consists of more than one file, make sure to turn them all in. In this case, you should turn in a *.ZIP file (not a *.RAR file). If you submit a ZIP file, or if your submission consists of a single file that's not written in Java, use your last name (family name) as the name of your file. In any case, make sure that your name and the assignment number appear on all of your documents (both hard and soft copies). Also please proofread your hard copy -- text that looks good in color on a screen may be hard to read on a black and white printed page. Proper indenting and use of extra blank lines can make a big difference in readability. Do not edit your output, even to make it look nicer. It's ok to write your name by hand on the hard copy of your output, to identify it as yours.
For both soft and hard copies, please turn in only files that you have created or modified. In particular, do not turn in unmodified library files or files that I have provided and you haven't changed. You needn't turn in any HTML files generated by Javadoc. You needn't turn in any object code. Please do not use folders or subdirectories unless absolutely necessary (e.g., to implement Java packages).
Sometimes deductions for compiler or run-time errors will be less than suggested above, if it is easy for me to determine the cause of the error. Unfortunately, I don't have time to debug every program that is turned in. It is easier for me to determine the cause of an error in a well-documented program than in a poorly-documented program. You may also reduce the deduction if you can show me (e.g., by submitting a revised version within one class day of the due date) that the error was small. It will be easier for you to get this partial credit if you make clear on the new version what changes you made and why.
In many cases it will be to your advantage to work on removing compiler errors, or in adding documentation, rather than in making improvements elsewhere in your program.
I reserve the right to make deductions in programming assignments for poor programming style, even when the specifications for the assignment are not violated. Normally these deductions are only a point or two, and are related to issues like poor user interface, poor layout of output, or gross inefficiency. They are more likely to be relevant in upper-division courses, where students can be expected to have a better-developed sense of programming style.
Do not modify or delete the test cases unless your program will not run with the original test cases. In this case you should document that you have changed the test cases, and you should expect to receive a significant deduction. You may add new test cases if you want; please document them. Note that the given test cases are not an exhaustive test; you can still receive deductions for errors even if you handle all the test cases correctly.