CIS 1100 Style Rubric

This page outlines the style rubric we look at when grading your homework assignment so that you can quickly refresh yourself on things to do when writing code. Note that this is NOT a general outline of why style is important or why a specific style error is considered in error. You can read more about that on the Style Guide resource page.

Note: We do not list how many points these deductions are worth. This is because the point weighting varies from assignment to assignment.

Overall Errors

These two style errors don’t follow a specific category and usually indicate more significant issues in the submission:

  • Incomplete Assignment. (Style points are only awarded for complete assignments)
  • Code did not compile, TA fixed errors and resubmitted.

Checkstyle Errors

There are two types of Checkstyle errors, one for the number of checkstyle errors, and one for the number of Checkstyle error types.

These two types of deductions are independent.

Number of Checkstyle Errors

  • More than 3 checkstyle errors
  • Less than 3 checkstyle errors

Number of Checkstyle Error Types

  • More than 3 types of checkstyle errors
  • Less than 3 types of checkstyle errors

Indentation Errors

  • Severely incorrect indentation errors that makes the code hard to read
  • Minor incorrect indentation

Class Header Errors

  • Missing or incorrect class header comment(s) with name and PennKey
  • Class header contains PennID instead of PennKey
  • Class header has no/incorrect program description (compounds with not having a header at all)
  • Class header has no/incorrect program execution (compounds with not having a header at all)

Variable Naming and Declaration Errors

  • Declaring and initializing variables on separate lines. Whenever feasible, this should be done on the same line.
  • Variable names are not descriptive
  • Variable names are not camelCase (except for constants, which should be ALL_CAPS_WITH_UNDERSCORES)

Commenting Errors

  • No commenting where it would be useful
  • Too many comments where it is not useful
  • Comments are below the code they reference
  • TODO comments left in code when that TODO was completed. These should be replaceed by your own comments as you fill in your code.
  • Commented out code left in your submission

If Statement and Loop Errors

  • Single line if statement or loop statement without brackets.
  • Uses a while loop where a for loop would work just as well.
  • Conditional check in the form of if (booleanExpression == true) {} - since the variable is a boolean already, you don’t need to compare it to true.
  • If statement to the effect of 
    if (x == y) {
    return true;
} else {
    return false;
}

    Instead of evaluating the conditional, we can just use it directly since it already results in a boolean. For the example provded above, we could rewrite it as just:

    return x == y;

Inefficiency Errors

  • Obvious code innefficiency
  • Overly complicated logic
  • Unnecessary print statements

Spacing Errors

  • Inconsistent brackets (sometimes same line, sometimes next line)
  • Unnecessary spacing
  • Inconsistent spacing
  • No spacing at all (i.e. no blank lines between code)