Course Project

Project: Submission & Grading

  • Everything is cleaned up and in good shape according to the Style Guide.
  • The code works.
  • No, really, you tested the project that one extra time even though you already know that it’s working just to make sure it’s still working!
  • The README.md file contains the final report.
  1. Double check everything in the checklist above.
  2. Write “Ready for grading” on the final commit message.
  3. Push!
  4. You pushed, right??

Your final project grade is based on both the project quality and your individual contributions. After you submit your project, your instructor will ask you to complete a questionnaire describing the work that each team member did. Look for that questionnaire in your email. Your project is not submitted until you fill out that questionnaire!

What your instructor will look for when grading projects:

  • Does it work? Did you test your code carefully and think about corner cases?
  • Is the code readable, tidy, and clear? Does it follow the Comp 127 style guide
  • Is the project creative? Did you challenge yourself?

Here is the rubric we use for assigning grades:

User experience and functionality (approx. 2/3 of total)

95+

Creative, challenging, a pleasure to use:

  • Shows attention to detail
  • Shows care and polish in user experience
  • Has imaginative / creative touches
  • Tested carefully
  • Works reliably
  • Students challenged themselves, but chose their challenge wisely so they could make it really good

90

Essential functionality works well enough to truly enjoy despite some minor bugs, glitches, and/or usability loose ends

85

Basically works, but bugs or omissions greatly impact usability; not polished; does not work reliably

80

Clear progress toward working code, but has essential functionality gaps or serious bugs; not really usable

75

Visible progress, but mostly not working

<70

Judgement call

Code style and structure (approx. 1/3 of total)

95

Exemplifies the points in the style guide:

  • Clear efforts to make code readable: good class names, good method names, good variable names, good comments where they are helpful, effort to group things in ways that make sense
  • Proper indentation, readable formatting
  • Good problem decomposition
  • Every class and method has a clear purpose, and a name that reflects that purpose
  • Classes don’t have lots of semi-unrelated instance variables
  • No large chunks of repeated or nearly-repeated code
  • No unused / defunct code, no unused variables, no commented-out fragments
  • No massive methods
  • Good division of labor between classes
  • Uses good tools for solving problems: library methods when appropriate, appropriate data structure choices (Map vs List vs Set, custom classes instead of deeply nested lists of lists of lists)

90

“A on Breakout” level of code quality: sensible enough organization, decent names for things, no egregious messes, at least some effort to comment

85

General structure makes sense, but is not well decomposed; some names are confusing; some messy organization or formatting; some repetition; still shows some effort toward organization and readability

80

Code works but shows little attention to anything beyond just getting it to work; general structure is a bit confusing, doesn’t show a fully thought-out design; code is messy and has repetition

75

Spaghetti code, mangled formatting / indentation, some stretches are incomprehensible, barely works

<70

Judgement call