This document lays out common criteria used to grade code i this clsas. Each criterion has a number of 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.
This is the most important criterion. A program must meet its specifications and function correctly. This means that it behaves as desired, producing the correct output, for a variety of inputs. This criterion includes the need to meet specifications by writing a program in a particular way or using a particular language feature, if such a thing is mentioned 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.
Code needs to be readable to both you and a knowledgeable third party. This involves:
Code written to be readable (as above) is ideally "self-documenting" to some extent. The organization of the code and the naming of variables and functions should explain what the code does as much as possible. Additional documentation that is almost always needed, however.
Every file should start with a file header comment. At the very least, this header should contain a title (which could just be the name of the file), the name of its author(s) (you), the date it was written, and a brief description of what the included code does. You might also want to include 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.
Every class and function should be documented with an initial comment. Use Python's "docstring" comment feature to add documentation to classes and functions that can be automatically parsed and presented to you as part of your editor's contextual help (i.e., tooltips that provide helpful information as you code). Docstrings for functions should describe the function, its parameters (if any), and its return value (if any) following a format described in class/lab.
All code should also be well-commented with inline comments. This requires striking a balance between commenting everything, which adds a great deal of unneeded noise to the code, and commenting nothing, in which case the reader of the code (or you, when you come back to it later) has no 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.
Inline comments should do things like (this list is not exhaustive):
And inline comments should not just restate what a line of code does. In simple statements, the code itself tells us that. Comments should not repeat things that can be immediately seen and understood from the code itself.
There are often many ways to write a program that meets a particular specification, and several of them are often poor choices. This covers the organization of your code (functions, classes, methods) and data (attributes, data structures), as well as the efficiency of your code in terms of its length and its runtime. Something may be inefficient because it takes many more lines of code (and thus your effort and time) than needed, or it may take much more of the computer's time to execute 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 latter is far superior and greatly preferred, not only because it makes it faster to both write the code and read it later, but because it makes it easier for you to change and maintain.
Assignments will usually contain specifications and/or requirements outside of the programming problems themselves. For example, the way you name your files to submit them will be specified in the assignment. There may be questions posed within the assignment that need to be answered in your submission. Other instructions may be included as well, so please read all assignments very carefully.
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 particular criterion roughly along the lines of the guidelines of the "Excellent," "Adequate," "Poor," and "Not Met" evaluations.
For example, a problem that was "Adequate" in the Program Spec./Correctness criterion, "Poor" in readability, and "Excellent" in all other areas would receive:
0.8*0.4 + 0.6*0.2 + 1*0.2 + 1*0.1 + 1*0.1 = 84%
| Criterion | Approx. % of Grade | Excellent (100%) | Adequate (80%) | Poor (60%) | Not Met (0%) |
|---|---|---|---|---|---|
| Program Specifications / Correctness | 40%* | No errors, program always works correctly and meets the specification(s). | Minor details of the program specification are violated, program functions incorrectly for some inputs. | Significant details of the specification are violated, program often exhibits incorrect behavior. | Program only functions correctly in very limited cases or not at all. |
| Readability/Style | 20% | No errors, code adheres to the style guide and is clean, understandable, and well-organized. | Minor issues with consistent indentation, use of whitespace, naming, or general organization. | At least one major issue with indentation, whitespace, names, or organization. | Major problems with three or four of the readability subcategories. |
| Documentation | 20% | No errors, code is well-documented throughout. | One or two places that could benefit from comments are missing them or the code is overly commented. | File header missing, complicated lines or sections of code uncommented or lacking meaningful comments. | No or very few comments present. |
| Code Design & Efficiency | 10% | No errors, code uses the best approach in every case. | N/A | Code uses a poorly-designed or inefficient approach in at least one place. | Many parts of the code could be cleaner, easier, faster, or otherwise better. |
| Non-code details | 10% | No errors | N/A | Minor details of the assignment specification are violated, such as files named incorrectly, questions answered poorly, extra instructions slightly misunderstood, etc.. | Significant details of the specification are violated, such as extra instructions ignored or entirely misunderstood. |
* As a special case, if a program does not meet the specifications at all / is entirely incorrect, no credit will be received for the other criteria either.
Other unexpected situations may result in diverging from the rubric as written as well, though this will be rare.