his document lays out common criteria used to grade CS127 programming

assignments. 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.

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 CS 127, we 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
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.

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 likeprincipal, 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. Functions should be defined in one section
of the program, 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 and more code in CS 127, and so few points, if
any, will be taken off for organization issues that we have not yet addressed in
class.

Documentation
Every file containing code should start with a header comment. At the very least, this
header should contain the name of the file, a description of what the included code
does, and the name of its author (you). 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 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. Like code organization, appropriate commenting is
also something we will be learning about as we write code throughout the semester
in CS 127, so while corrections may be made, points will only be taken off for things
that have been emphasized in class already.
This style guide from CalTech has some good guidelines for writing comments,
starting here.

Code Efficiency
There are often many ways to write a program that meets a particular specification,
and several of them are often poor choices. They may be poor choices because they
take many more lines of code (and thus your effort and time) than needed, or they
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.

Assignment Specifications
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 to the course website will be specified in the assignment. Other
instructions may be included as well, so please read the assignments carefully.

Grading Standards
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 marked as "Adequate" in the Program
Spec./Correctness criterion, "Poor" for readability, and "Excellent" in all other areas
would receive:
0.8*0.5 + 0.6*0.2 + 1*0.2 + 1*0.05 + 1*0.05 = 82%
Approx.
Criterion % of Excellent (100%) Adequate (80%) Poor (60%) Not Met (0%)
Grade

No errors, program Minor details of the Significant details of

Program only
Program always works program specification the specification are
functions correctly
Specifications / 50%* correctly and are violated, program violated, program
in very limited cases
Correctness meets the functions incorrectly for often exhibits
or not at all.
specification(s). some inputs. incorrect behavior.

At least one major

No errors, code is Minor issues with Major problems
issue with
clean, consistent indentation, with at three or
indentation,
Readability 20% understandable, use of whitespace, four of the
whitespace, variable
and well- variable naming, or readability
names, or
organized. general organization. subcategories.
organization.

File header missing,

One or two places that
complicated lines or
could benefit from
No errors, code is sections of code No file header or
Documentation 20% comments are missing
well-commented. uncommented or comments present.
them or the code
lacking meaningful
isoverly commented.
comments.
 Many things in the
No errors, code code could have
Code uses poorly-
uses the best been accomplished
Code Efficiency 5% N/A chosen approaches
approach in every in an easier, faster,
in at least one place.
case. or otherwise better
fashion.

Minor details of the

assignment Significant details of
specification are the specification are
Assignment violated, such as files violated, such as
5% No errors N/A
Specifications named incorrectly or extra instructions
extra instructions ignored or entirely
slightly misunderstood.
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.