Base Grading Guidelines

These guidelines will apply to every problem set in the course—keep them in mind as you navigate the specifics of each assignment! They are, by design, general. Guidelines on assessing a student’s algorithm or approach can be found in problem-specific guidelines.

What to Look For

Evidence of a 5-Point Submission

Clean. Once it’s time for submission, a student should ideally scrub off any scrap-work parts of their code. Examples of this include, but are not limited to:
1. The declaration of variables or functions that never get used
2. The inclusion of libraries that never get used
3. Commented-out blocks of code that serve no purpose to the finished product
Mastery of control flow. A 5-point submission’s control flow should be exceptionally clear. A submission might opt for “guard clauses”, if-statements that catch and handle unexpected or undesirable cases, instead of packaging code into one large if block on a success.
Sensible naming scheme. A submission’s naming scheme, including function names, variable names, etc., should be as conducive to understanding as possible. A variable’s name should reference its purpose or context—for instance, calling the variable for the pyramid’s height in Mario “height” or something similar. If a student uses single-letter variable names, except, e.g., when using i and j for loops, it’s likely the submission is not a 5-point submission.
Tight scoping. Variables should be defined with as small scope as is reasonable. If a variable is only used in some function, that variable should be defined within that function—otherwise, it’s putting undue strain on an outside reader’s memory. In particular, global variables should be used with some caution. If a variable was defined globally when it needn’t have been, it’s likely the submission is not a 5-point submission.
Well-commented. A 5-point submission should include a few helpful and appropriate comments to aid the exposition of their code to a newcomer. There’s no quota to meet here: if an assignment is short, only a few comments are needed! These needn’t follow any strict formula, but one thing to watch out for is potential over-commenting. For instance, consider the following Mario code:
```
  // Declare an integer for the height
  int height;

  // Begin a do loop
  do
  {

      // Get a value for height from the user
      height = get_int("Height: ");
  }

  // Repeat the above while height is less than one or height is more than 8
  while (height < 1 || height > 8);
```
There are two faults here: (1) the comments are numerous to the point of making it more difficult to read, not easier, and (2) the comments don’t provide much substance—each comment is simply a translation of the C code it’s attached to. Consider, then, the following code:
```
  // Prompt user for pyramid's height;
  // only proceed if height in range 1-8
  int height;
  do
  {
      height = get_int("Height: ");
  }
  while (height < 1 || height > 8);
```
In this example, comments are explanatory, concise, and well-placed. You can advise students their comments should be written with a certain audience in mind: namely, a technically-literate person who knows the language you’re using, but would nonetheless appreciate clarification on the purpose of each part of their program.

Evidence of a 4-Point Submission

A 4-point submission resembles a 5-point one, but with a few small design mistakes. These vary from assignment to assignment, but some of the common errors you might see are:

Broad scoping. In contrast to keeping variables only to the scope in which they are needed, a submission might define variables in a larger scope than is necessary.
Control flow improvements. Particularly when validating command-line arguments or checking input from a user, code should opt for “guard clauses” that catch and handle undesirable cases, instead of placing code in one large if-statement.
Opportunities for abstraction. Code should be segmented into helpful, easy-to-understand chunks with line breaks. Watch out if everything’s all in one big block.
Sparse commenting. Comments are sparse enough or crowded enough to hamper understanding.
Uninformative naming scheme. In contrast to names that make clear a function or variables purpose, a submission might provide names that are too vague.

Evidence of a 3-Point Submission

A 3-point submission resembles a 4-point one, except that it might have a number of small mistakes or one or two more serious errors in design, including those options listed above. The specifics typically depend on the assignment, but 3-point submissions tend to result in slower performance.

Evidence of a 2-Point Submission

A 2-point submission resembles a 3-point one, but with the additional presence of a significant number of serious errors. If the nature of the implementation suggests an incomplete understanding of the week’s material, this might be an appropriate score.

Evidence of a 1-Point Submission

A 1-point submission may have some very grave errors that suggest the student may have missed a core concept or piece of knowledge from the week’s material. These also depend on the assignment, but a common theme among them is that they involve hard-coding or brute-forcing some solution. The solution doesn’t leverage the power of computer programming to solve the problem.