Assignments, CS 146

For full credit, assignments are to be turned in so that I receive them on the announced due date. If you turn them in to the 4th floor pigeonholes or to the department office, you run the risk that I might not find them on time (the department staff might note the time they received your assignment if you ask them nicely). The safest bet for last-minute submissions is to turn them in under my office door. There are very few circumstances which will convince me to extend the due date. In particular, minor system crashes and data loss are inevitable and should be allowed for.

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 at the next class meeting would receive a penalty of half of 20-30%. If it was otherwise completely 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). If I return the earlier version on the day that you turn in a later version, please resubmit the hard copy of the earlier version on that day -- I will need it to complete the grading.

Programming assignments

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 (about 2 points of 100) 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 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 the diskette and hard copy, 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, and do not turn in files for other assignments or other classes. 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. 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.

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 might 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. You are also responsible for understanding the department's Java coding style guidelines. You should expect deductions for Java programs that violate these guidelines.