Assignments

For full credit, submissions for assignments are to be turned in so that I receive them on the announced due date. If I do not specify a deadline time, by default it is at the scheduled end of my last class of that day. So submissions made 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 in the specification of an assignment, or perhaps for the last assignment of a semester, I will accept submissions 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 there were no other deductions, 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.

It never hurts to turn in an assignment on the due date, even if it isn't fully 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 a hard copy of an 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.

Submissions

Depending on the course and the assignment, I may ask for submission through D2L, by hard copy only, by soft copy only, or by a combination of hard and soft copy.

In any case, your source code should consist entirely of plain text files (which need not have a txt extension) that include your name and the assignment number.

For both soft and hard copies, 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. Do not turn in soft copies of your output unless you were explicitly instructed to. Do not turn in any object code or any HTML files generated by Javadoc unless I have asked you to do so. Do not turn in files for other assignments.

For both soft and hard copies, 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. Do not edit the test program unless your program will not compile or run otherwise -- even if you think the output looks better with your changes. You may of course use your own personal version of the test program for debugging purposes.

Small penalties (no more than 5% of the maximum grade for each violation) will apply in cases of failure to meet the specifications for submission (e.g., excess soft copy files, or no hard copy when one is required).

Email submissions

Email submissions are to be identified in the subject line as homework submissions, 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 your solution consists of just one file, simply attach it to your message. If the programming language you used allows you to choose your own file name, use your last name (family name) as the name of your file (with an appropriate extension). Otherwise (e.g., for Java), use the file name required by the language.

If your solution consists of more than one file, attach to your message a *.ZIP file (not a *.RAR file) that contains all of your source code files. The name of this zipped file is to be your last name (family name). Unless you are using an explicit Java package (or analogous construct in another language), do not use folders or subdirectories. If you are using an explicit Java package, use a folder whose name matches the package name.

If any part of a submission is to be sent by email, then be careful about emailing me a question about the corresponding assignment. In particular, if the subject line of your message suggests that it is a submission of an assignment, I may not answer it promptly. For the same reason, please do not include any questions with a submission. I usually delete email messages containing a submission once I have downloaded, compiled, and run the code.

Hard copy submissions

An important purpose of hard copies is to serve as an unambiguous permanent record of deductions, my comments, and the assignment grade. If you are turning in both a hard copy and a soft copy, the hard copy is the official version; it is your responsiblity to make sure that the soft copy matches it. Please give special attention to proofreading any hard copies -- for example, text that looks good in color on a screen may be hard to read on a black and white printed page. The hard copy of your output should have your name on it (handwritten is ok).

Grading

Normally, for a program to receive a grade as high as 60%, it will have to compile, be reasonably well documented, and produce nontrivial output. Programs that fail to compile might receive a score as high as 40% if they are relatively complete and well documented. Programs without documentation might receive no more than 80%, 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. It is much 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, excessive line length, uninformative error messages, violation of coding style guidelines (see below), 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.

Output

For some assignments, it will be immediately clear what output your program should produce. For other assignments, especially in upper-division classes, it will be less clear. Normally, this lack of immediate clarity is deliberate. Part of what you should be learning as a CS student is the skill of determining whether your answers are correct without having an outside authority tell you so. In the real world, problems don't always arrive labeled with answers. Finding answers for small input can usually be done by hand. For larger input, time complexity results can often be useful (e.g., if the assignment asks you to count element comparisons). Often a debugger is useful in checking partial solutions, and their combination into final answers.

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 to the end of my test cases; please document them if you do. 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.

Other information

Please read the the separate handout on documentation standards. This handout is part of the official course green sheet for those of my courses that have programming assignments. Also see the department's Java coding style guidelines. This document is part of the official class greensheet for those of my courses that have Java programming assignments, but only in the sense that you are responsible for understanding these guidelines, and that you should expect deductions for Java programs that violate these guidelines (except as noted in the handout on documentation standards). Finally, see the web page on collaboration. This document is part of the official course greensheet.