CS439 Grading Criteria
This sheet serves two purposes. First, it is an attempt to standardize the grading of TAs and proctors and to minimize differences between graders. A given program should receive the same grade regardless of who grades it. Second, this guide can serve as a checklist so students can self evaluate programs. When you turn a program in have you meet all of the following criteria? If not, do not be surprised when the grader takes points off. Assignments are mostly for learning, but we do want to provide an evaluation on how well you did to aid in your learning.
If you turn in a project with an incorret name, you will not receive a grade for that project.
Assignments are worth 100 points. The point breakdown is as follows:
***For Project 0, the breakdown changes to: Correctness (60%), Documentation (10%), and Design (30%). The desciptions of each category remain the same.***
The correctness category measures solely whether your code meets all requirements in the specification and functions correctly. An automated grading system will do the bulk of this grading, so be certain that your program produces output that is consistent with all requirements in the assignment handout as well as any sample programs that have been made available.
If you turn in a program that fully meets the requirements, then you will receive full credit for this portion of your grade. "Degrees of working" will result in lower scores.
There is no excuse for turning in a program that will not compile properly. Programs that do not compile will receive 0 points for the correctness portion. You should test that they code you turned in compiles and runs as your expect by downloading it to a new directory, compiling it, and running it. If anything differs, correct the mistakes and resubmit. You can submit a project to turnin as many times as you like; it only saves the most recent.
The documentation category measures any documentation you provide within the code itself---code comments, and code readability (follow the C Style Guide!). Included in the documentation category is your use of descriptive variable names.
Also included in this category is whether or not you checked the return values from library and system calls and how well you organized memory. Memory organization includes such things as appropriate memory allocation for variables. For example, use of static declarations is discouraged unless absolutely necessary. Likewise, use of the routines in the malloc(3) library is strongly recommended for allocating space for dynamic structures.
The design category measures the understanding demonstrated by your design document and the cleanness of your solution. It is expected that your design documents will provide thorough and concise explanations of the design of your system, and that the various sections of your program will be organized in a clean and logical manner. A good design is easy to understand, makes good use of functions, groups related functions, and is efficient. Functions should be small enough to fit on a single page (roughly 70 lines of text). Func>tion names should be as meaningful and descriptive as possible.
Adapted from grading criteria by Jim Greenlee and Mike Scott (who adapted from Hal Perkins of UW).