An assignment that I receive before the end of my last scheduled class on the due date will count as being on time.
Except perhaps for the last assignment of a semester, I will accept assignments up to one class day late, with a 20%-30% penalty on those parts that are late. Anything after this does not count. For example, a 100-point assignment that was turned in half on the due date and half on the next class would receive a penalty of half of 20-30%. If everything turned in was correct, it would probably get an 87. Late submissions should be turned in by the beginning of class. Late submissions may not be graded as promptly as work turned in on time.
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).
Turn in (1) a printed copy of the source code of your program, and the results of its execution, and (2) a diskette containing the source code. The purpose of the hard copy is to serve as a permanent record of deductions, my comments, and the assignment grade. Small penalties will apply if you fail to turn in a hard copy, and may apply if you turn in your program by email rather than on diskette.
If your solution consists of more than one file, make sure to turn them all in. Make sure that your name and the assignment number appear on all of your documents, and on the diskette. Also indicate the top level class or function on the diskette, if appropriate (as well as the pathname, if necessary). 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 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.
Please do not turn in copies of library files or files I provide, unless you have modified them. You needn't turn in any HTML files generated by Javadoc. Don't modify or delete the test cases. You may add new test cases if you want.
Normally, for a 100-point program to receive as many as 60 points, it will have to compile, be reasonably well documented, and produce nontrivial output. Programs that fail to compile might receive as many as 40 points if they are relatively complete and well documented. Programs without documentation may receive no more than 80 points, depending on their complexity and need for documentation. 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. 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. You should also consider modifying the test program if this will remove run-time errors, although you can expect a deduction for doing so.
Please read the the separate handout on documentation standards, and see the web page on collaboration.