Computer Science 15-110, Spring 2010
Style Rubric

Style is typically worth about 15 points on each hw. Each style issue is either entirely right or not. So if you have ONE line beyond 80 characters, then you lose the 2 style points for that issue. If you have 50 lines beyond 80 characters, you do not lose 50x those points. You just lose them once per issue.

While you may in theory lose up to 5*4 + 2*15 = 50 points, there are no negative style grades. Lowest style grade is 0.

  1. 5-Point Style Issues
    1. Compile without errors (even if your code has logical errors or runtime errors!).
    2. Use correctly-named files with correctly-named methods (where applicable)
      (Note: simple rule -- it is a 5-point penalty if CA's must manually edit your code to get the autograder to work)
    3. Use comments
      (Note: not using any comments is a 5-point error; not using enough comments is just a 2-point error.)
    4. Use top-down design with unit testing
      (Note: not using any helper methods (where appropriate) or any test methods is a 5-point error; not using enough is just a 2-point error.)
  2. 2-Point Style Issues
    1. Include your name, andrew id, and section in a comment at the top of every file you submit
    2. Use a clear, robust design
    3. Use meaningful variable and method names (whenever possible)
    4. Use proper mixedCase/camelCase naming
      1. Variable names start lowercase (eg: tetrisPiece)
      2. Class names start uppercase (eg: TetrisPiece)
      3. File names match class names (start uppercase)
      4. Constants ("final" variables) are all uppercase (with underscores) (eg: TETRIS_ROWS)
    5. Include all obvious boundary cases in test methods
    6. Do not have more than 15 lines in any one method (or 20 lines for graphics methods).
      (While it is possible to have a well-written 15+ line method, we need a simple hard-and-fast rule for grading purposes...)
    7. Comment liberally but not excessively, using clear language in comments
      (Note: if you do not write any comments, then you lose 5 points from the previous list and so this item would not apply here.)
    8. Do not exceed 80-characters in any one line
    9. Indent properly.
    10. Do not use magic numbers.
      In particular, every number besides -2, -1, 0, 1, or 2 must be stored in a well-named variable.
    11. Do not be grossly inefficient
      (You are generally not responsible for efficiency in 15-100, and you do not have to use the most efficient solution in general; but the exception is if you are truly "grossly" inefficient, particularly if your approach is also unclear, and especially if you had simple, clear, and reasonably efficient options to choose from.)
    12. Do not duplicate code
    13. When appropriate, provide meaningful UI (clear prompts, clear output)
    14. Use "else" where appropriate
      So this code loses 2 points:
        if (x < 2) foo();
        if (x > 3) bar(); // <- should be "else if"
    15. Follow other guidelines as described in the class notes

carpe diem   -   carpe diem   -   carpe diem   -   carpe diem   -   carpe diem   -   carpe diem   -   carpe diem   -   carpe diem   -   carpe diem