CS439 Grading Criteria

This guide provides an overview of how your projects will be evaluated, though more specific rubrics will be published with each project. 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 incorrect name, you will not receive a grade for that project.

• Test Cases

  The test cases category measures solely whether your code successfully passes all given test cases. 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 execute. Programs that do not execute will receive no credit for the test cases portion. You should test that the code you turned in executes as you 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.

• Design, Design Communication, and Documentation

  This category measures the understanding demonstrated by your design document, whether your code meets all requirements in the specification, whether it can be expected to function correctly in all situations, 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.

  This category also evaluates any documentation you provide within the code itself---code comments, and code readability (follow the C Style Guide!). Included in documentation is your use of descriptive variable and function 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.

• Miscellaneous Criteria Related to Failures in Following Instructions
• Missing README file or incomplete information in README file

  Test cases grade reduced by a category.

• Failing to follow all group programming guidelines, including missing, incomplete, or misplaced pair programming log or failting to commit every thirty minutes

  Test cases grade reduced by a category, with 3 being the maximum possible score.

• Working alone on a pair or group programming assignment for more than 5% of the total time, as allowed by the syllabus

  0 on the assignment.

• Code fails to compile or execute

  0 for the test cases grade.

• Improper turnin (including late, wrong directory, wrong name, incorrect tarfile, etc.)

  0 on the assignment.

• Design document over the character limit

  Design score will be a maximum of a 3, and it may be a 2, depending on how far over the character limit the document is.

Adapted from grading criteria by Jim Greenlee and Mike Scott (who adapted from Hal Perkins of UW).