The rubric below defines several programming code assessment categories. Each category contains criteria related to an assessment score in the range of [0,5], with a description of the meaning of that score. The descriptions may include several independent criteria; if so, each is considered sufficient to select a particular point assessment. It is not necessary that all criteria be met to receive a particular assessment. Independent criteria will be separated by periods, dependent criteria will be separated by semicolons. Not every category will be appropriate for every programming assignment, so individual assignments may not be assessed in one or more category; categories may also be independently weighted to provide emphasis on featured skills in an assignment.
Any category may also be assigned points from the range [0,3] by mapping the 5 point level to +3, the 3 & 4 point level to +2, the 1 & 2 point level to +1, and the zero level to +0.
Information about categories chosen, category weighting, and whether the [0,3] or [0,5] point scales were used should be made available along with other assessment feedback.
Program Correctness Criteria
[C] Code/Algorithm Correctness
Used to evaluate the technical correctness of the computations performed by your code; this category is used for most programming assignments, and may be weighted higher than others.
|+5||Algorithm is functionally correct; no logic errors for test conditions.|
|+4||A single error or very minor errors in code/algorithm, may or may not have affected test cases.|
|+3||Few errors in code/algorithm, affecting one or more test cases.|
|+2||Many errors in code/algorithm, affecting most test cases.|
|+1||Code/algorithm is only correct in special or single case.|
|+0||Did not compile or completely incorrect functionality, logic, or algorithm. Program does not demonstrate a solution to the problem as assigned.|
[O] Output Correctness
Used to evaluate the correctness of the output produced by your program, the adherence of your user interface to requirements presented in the assignment; typically selected in situations where the output or user interface have requirements and specifications set forth in the assignment.
|+5||Correct: Expected output is produced for all test cases.|
|+4||A single error or very minor errors in expected output.|
|+3||Few errors in expected output.|
|+2||Many errors in expected output.|
|+1||Output is only correct in special or single case.|
|+0||No output, completely incorrect output, or did not compile.|
[T] Testing Rigor
Used to evaluate the thoroughness of your testing code and test plan; typically selected in situations where testing is requested by the instructions, or where you are developing general-purpose functionality or a library.
|+5||Tests are thorough and exercise all boundary conditions; testing provides positive assurance that no algorithm or logic errors are present.|
|+4||A single or very minor omissions in test conditions; testing is sufficient for all likely states of the algorithm.|
|+3||Few omissions in test conditions, omitting one or more likely states of the algorithm. Some boundary conditions not checked.|
|+2||Tests omit many possible conditions. Many redundant tests examine the same conditions with no contribution to algorithm quality. No thought given to boundary conditions.|
|+1||Testing only provides assurances for the most common or "perfect world" states of the algorithm.|
|+0||No testing code was provided, or tests were inadequate to provide any assurance of correctness, or did not compile.|
User Interface Criteria
[Q] Output Quality
Used to evaluate the quality, simplicity, and intuitiveness of the user interface or the program's output data; typically selected in situations where you have creative control over the appearance of interfaces or output presentation.
|+5||Excellent output format; very visually compelling; exceeds output requirements.|
|+4||Good output format; somewhat visually compelling; meets output requirements.|
|+3||Mostly correct output format; not visually compelling.|
|+2||Some errors in output format; fails to meet requirements.|
|+1||Significant errors in output format; items are hard to identify.|
|+0||Output items lack all formatting and cannot be identified, or did not compile.|
Code Quality Criteria
[S] Style, Coding Constructs, and Layout
Used to evaluate the overall adherence of your code to the style guidelines for the course, including indentation, alignment, use of whitespace, and choice of appropriate language components when such a choice is possible. This category is selected for most programming assignments.
|+5||All style and punctuation guidelines are observed; simple and elegant program constructs; program layout, indentation, and separation are consistent and attractive; no required functionality is omitted or left as a stub.|
|+4||Naming, style, and punctuation are mostly correct and consistent, but occasional errors are found; program constructs are appropriate; program layout, indentation, and separation are generally consistent; Exceptions do not affect readability; no or a negligible amount of required functionality is omitted or left as a stub.|
|+3||Naming, style, and punctuation are generally correct and consistent, but several errors are found. Program constructs are appropriate but could have been simplified. Program layout and indentation are acceptable, though inconsistencies affect readability. Few procedures are stubs lacking required functional code.|
|+2||Inconsistent punctuation and naming of identifiers make code difficult to follow. Program constructs are inappropriate. Program layout and spacing are generally inconsistent and affect source code readability significantly. Some procedures are stubs lacking significant functional code.|
|+1||Naming, style, and punctuation guidelines are generally ignored. Program constructs are unnecessarily complex. Minimal attention is given to layout, indentation, and separation. Horizontal and vertical spacing are mostly nonexistent. Selections of code are very difficult to read. Many procedures may be stubs lacking functional code.|
|+0||Naming is inconsistent and misleading. No punctuation guidelines are observed. Program constructs are excessively complex, requiring significant effort to comprehend. No considerations are given to layout, indentation, and separation. Program is unreadable. Functional code is nonexistent, or only shell code is provided; not enough functional code to judge style criteria.|
[D] Documentation and Self-Documenting Code
Used to evaluate your adherence to the documentation guidelines for the course, as well as the degree to which your code is "self-documenting"; this category focuses on the ability of a programmer to easily read, understand, utilize, and reason about your code without needing external information. This category is selected for most programming assignments.
|+5|| Documentation is exemplary and provides accurate information at an appropriate level of details; all required elements are present and follow the prescribed format; non-obvious sections contain in-code comments; in-code comments add valuable contextual information where present.
Code is self-documenting: Identifiers are descriptive and follow naming conventions; source code is highly readable; purpose and context information is directly stated by source code as written, or in-code comments have been added to clarify.
|+4|| Documentation given is correct and mostly complete, but one or two minor items are missing; documentation is complete, but minor errors are present. While the prescribed format is used, details may be lacking in some instances. Some in-code comments may not add new information, or a non-trivial section should have been commented but was not.
Identifiers are mostly descriptive and follow naming conventions, with at most one or two exceptions; source code is readable; source code is mostly self-documenting, with purpose stated directly in code, with at most one or two exceptions.
|+3|| Documentation follows the prescribed format but includes a few required elements at a level that is too general; details are lacking in some instances. In-code comments may be lacking, or fail to provide new information in a few non-trivial sections.
Identifiers are somewhat descriptive, but a few are too abbreviated, ambiguous, or are in a non-idiomatic form; source code may be hard to read in one or two places; code is somewhat ambiguous in a few places, or a few sections of non-trivial code lack context and no useful in-code comments are provided.
|+2|| Documentation is acceptable but ignores the prescribed format in many places and may lack one or more required items. Difficult sections of code lack comments. Missing functional code severely reduces the available in-code documentation that can be judged.
Identifiers are too abbreviated, ambiguous, or in non-idiomatic forms in many cases; source code is difficult to understand by simply reading, and does not "self-document" well; code that is difficult to follow also does not contain in-code comments to assist.
|+1|| Documentation is minimal and uses an incorrect format. Few, if any, in-code comments are given; those that are present rarely impart new information. Not enough functional code to judge in-code documentation.
Most identifiers are far too abbreviated, ambiguous, or formed in non-idiomatic ways; source code is very difficult to read and reason about, forcing "on-paper" tracing to follow the logic; naming choices may actually contradict the identifiers use in the code; in-code comments may actually contradict the logic of the code.
|+0|| The source code contains no documentation.
Code is not self-documenting: Identifiers give no indication of purpose, and in-code comments are inexistent or do not provide any useful contextual information. Not enough functional code to judge its self-documenting nature.