Grading Rubric
As noted on the Grading Guidelines page, we look at more than just how well your code solves the problems in your assignments. This page provides more detail about what we're looking at and how it might affect your grade.
Written Work
Category | Clarity | Completeness | Correctness |
---|---|---|---|
Excellent | Clear and easy to tell if the answer is correct or not. | Complete | Correctly addresses all parts of the question. |
Good | Clear in many places, but unclear in some; usually possible to tell if the answer is correct or not. | Correctly addresses some parts of the question, or has some minor conceptual flaws. | |
Developing | Unclear in many places; too much or too little writing; the ideas consistently don’t come through; often difficult to tell if the answer is correct or not. | Correctly addresses small pieces of the question, or connects to relevant concepts but has major conceptual flaws. | |
Missing | Missing or unreadable. | Missing | Missing or doesn't correctly address any part of the question. |
Code
Category | Clarity | Elegance | Style | Completeness | Correctness |
---|---|---|---|---|---|
Excellent | Documentation consistently makes the code clearer. | The code is modular and extensible. It uses helper functions where appropriate, it does not leak implementation details, it uses library calls where appropriate, it does not employ techniques that would be hurtful in large projects, and the code is clear and easy to believe correct or incorrect. | Layout and indentation is constent and uses a well-known style. Whitespace aids readability. Variable names are descriptive and adhere to CS70 style. Code uses idioms where appropriate. | Complete | Passes all tests. |
Good | Problems with documentation (e.g., under- or overcommenting, or comments that don’t match the code) resulting in minor impact on readability at the function level. | The code is missing some of the features described in “excellent”, resulting in minor impact on readability at the file or project level. | The code is missing some of the features described in “excellent”, resulting in minor impact on readability at the line level. | Passes most tests, but misses some edge cases. | |
Developing | Problems with documentation (e.g., under- or overcommenting, or comments that don’t match the code) resulting in significant impact on readability at the function level. | The code is missing some of the features described in “excellent”, resulting in significant impact on readability at the line level. | The code is missing some of the features described in “excellent”, resulting in significant impact on readability at the line level. | Passes basic tests. | |
Missing | Code is missing, or has nearly or literally no documentation. | The code is missing, or is monolithic, or too modular (e.g., too many helper functions); data structures leak implementation details, the code is redundant and could be generalized or replaced with library calls. The code employs many techniques that would be hurtful in large projects. Code is frequently difficult to follow, even when reading the comments. | The code is missing, or layout and indentation is frequently inconsistent and detracts from the readability of the code. Variable names are misleading or otherwise detract from readability. Code is idiosyncratic and doesn’t use appropriate idioms. | Missing | Missing, or doesn’t compile, or doesn’t pass basic tests. |
Idioms
- Proper choice of control flow statements (e.g.,
for
vswhile
) - No uses of post-increment when pre-increment is sufficient. (Homework 3 and later)
- Member functions refer to
foo()
andbar_
instead ofthis->foo()
or(*this).bar_
(Homework 3 and later) - Uses
foo->bar
instead of(*foo).bar
(Homework 4 and later)
Good Practices
- All constants other than 0 or 1 have meaningful names (no magic numbers)
- No top-level variables
- No deprecated library functions
- No disruptive control-flow statements (e.g.,
goto
) - All header files use
#include
guards (Homework 3 and later)
(When logged in, completion status appears here.)