Grading Criteria

This document lays out common criteria used to grade programming assignments. Each criterion has several different levels of achievement, with a description of how a submission will attain that level and the number of points assigned for reaching it. Please email or ask me if you have any questions about this rubric. Please refer to the grading rubric below.

Every criterion will make up an approximate percentage of the grade given to a single programming problem as indicated in the “Approx. % of Grade” column. Points will be assigned for a criterion roughly along the lines of the guidelines of the “Excellent,” “Above Average,” “Average,” “Below Average,” and “Not Met” evaluations.

For example, a problem that was “Above Average” in the Program Specifications/Correctness criterion, “Average” in readability, and “Excellent” in all other areas would receive:

(0.4 * 0.8) + (0.2 * 0.6) + (0.2 * 1.0) + (0.1 * 1.0) + (0.1 * 1.0) = 84% = B

Table 1: Grading Rubric

As a special case, if a submission lacks the name of the author, or, if a program does not meet the specifications at all (entirely incorrect), or, if a program is written in a language other than used in the course, no credit will be received for the other criteria either, i.e., these conditions will result in a score of zero.

Criteria

Program specifications / correctness

This is the most important criterion. A program must meet its specifications (whether from a textbook problem or as written in the assignment) and function correctly. This means that it behaves as desired, producing the correct output, for a variety of inputs. (In the beginning, I will be lenient with regards to producing correct output for all inputs, as we may not always have the tools needed to accomplish that, yet.) This criterion includes the need to meet specifications by writing a program in a specified way or using a required language feature, if such a thing is specified in the problem.

If a specification is ambiguous or unclear, you have two choices: You can either make a reasonable assumption about what is required, based on what makes the most sense to you, or you can ask the instructor. If you make an assumption about an ambiguous specification, you should mention that somewhere in a comment so that the reader/grader knows what you were thinking. Points may be taken off for poor assumptions, however.

Readability

Code needs to be readable to both you and a knowledgeable third party. This involves:

Using indentation consistently (e.g., every function’s body is indented to the same level)

• Adding whitespace (blank lines, spaces) where appropriate to help separate distinct parts of the code (e.g., space after commas in lists, blank lines between functions or between blocks of related lines within functions, etc.)
• Giving variables meaningful names. Variables named ‘a’, ‘b’, and ‘c’ or ‘foo’, ‘bar’, and ‘baz’ give the reader no information whatsoever about their purpose or what information they may hold. Names like ‘principal’, ‘maximum’, and ‘counter’ are much more useful. Loop variables are a common exception to this idea, and loop variables named ‘i’, ‘j’, etc. are okay.
• The code should be well organized. Once we have learned about functions, code should be organized into functions so that blocks of code that need to be reused are contained within functions to enable that, and functions should have meaningful names. This is a concept that we will be learning about as we write more code, and so few points, if any, will be taken off for organization issues that we have not yet addressed.

Documentation

Every file containing code should start with a header comment. At the very least, this header should contain your name, the name of the file, and a description of what the included code does. Other details you might include are the date it was written, a more detailed description of the approach used in the code if it is complex or may be misunderstood, or references to resources that you used to help you write it.