Programming Grading Rubric#

The current syllabus and applicable CSN or college policies are the official sources for semester-specific grading policy. This rubric explains common criteria used when grading programming assignments.

This rubric table is also included in the course syllabi. It is repeated here as a stable reference so you can review the criteria while working on programs. If the current syllabus, assignment instructions, or applicable policy differs from this page, follow the current syllabus, assignment instructions, or policy.

Each criterion has several levels of achievement, with a description of how a submission reaches that level. The “Approx. % of Grade” column shows the typical weight of each criterion for a single programming problem. Points are assigned roughly according to the “Excellent,” “Above Average,” “Average,” “Below Average,” and “Not Met” descriptions.

For example, suppose a problem is “Above Average” in the Program Specifications/Correctness criterion, “Average” in readability, and “Excellent” in all other areas. The score would be:

(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

The rubric focuses on five broad areas:

Program specifications / correctness: the program must solve the assigned problem and produce correct results.
Readability: the code should be organized, indented, and named clearly enough for another person to read.
Documentation: source files should include required header comments and helpful comments for non-obvious code.
Code efficiency: the solution should avoid unnecessary repetition, excessive work, and poor design choices.
Assignment specifications: the submission must follow the assignment’s required file names, language features, format, and other instructions.

As a special case, if a submission lacks the name of the author, if a program does not meet the specifications at all, or if a program is written in a language other than the one used in the course, no credit will be received for the other criteria. 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 expected, producing the correct output for a variety of inputs.

Early assignments may not yet require the same level of input handling or program design expected later in the sequence. 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 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, mention it in a comment so that the reader/grader knows what you were thinking. Points may be taken off for poor assumptions.

Readability#

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

Using indentation consistently, such as indenting every function body to the same level.
Adding whitespace, such as blank lines and spaces, where appropriate to help separate distinct parts of the code. Examples include spaces after commas in lists, blank lines between functions, and blank lines between blocks of related lines within functions.
Giving variables meaningful names. Variables named ‘a’, ‘b’, and ‘c’ or ‘foo’, ‘bar’, and ‘baz’ give the reader no information 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, and names like ‘i’ and ‘j’ are okay.
Organizing code well. Once functions have been introduced or required, code should be organized into functions so that reusable blocks of code are contained within functions. Functions should have meaningful names. Grading emphasis depends on the concepts and requirements that apply to the current assignment.

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.

All code should also be well commented. This requires striking a balance between commenting everything, which adds unneeded noise to the code, and commenting nothing, which leaves the reader without assistance in understanding the more complex or less obvious sections of code.

In general, aim to put a comment on any line of code that you might not understand yourself if you came back to it in a month without having thought about it in the interim. Like code organization, appropriate commenting is something we will learn as we write code throughout the semester. Corrections may be made, but points will only be taken off for things that have been emphasized in class already.

Code efficiency#

There are often many ways to write a program that meets a specification, and several of them are often poor choices. They may be poor choices because they take many more lines of code, more effort, or more computer time than needed.

For example, a certain section of code can be executed ten times by copying and pasting it ten times in a row or by putting it in a simple for loop. The loop is better because it makes the code faster to write, easier to read, and easier to change and maintain.

Assignment specifications#

Assignments will usually contain specifications or requirements outside of the programming problems themselves. For example, the assignment may specify how to name files for submission. Other instructions may be included as well, so please read the assignments carefully.