General notes on project grading

Each sprint the teams and projects will be evaluated in terms of project management (processes that your team follows - ex: task tracking, code analysis, code reviews), code functionality (has your team implemented enough work for its size and how buggy is it), and code quality (based on code quality metrics and code smells). Each sprint your team will receive comments on any short-comings in each area as well as a rough grade for the sprint as a whole.

Notes on the areas of evaluation

Project management is the most difficult of these for us to observe (and thus has the lowest weight when it comes to determining final scores), and will require investigation of texts and tools not covered in class if you want to really impress us. Dedication to following a process and documenting the results is more beneficial to learning than attempting to get 100% accuracy (task time estimation is a good example).

Breadth of features and correctness is expected on your projects. However, we do not expect your implementation to be exactly the same as the game you are based yours off of, some objects may move faster or slower, enemy movement may be altered, etc. Adding more features than is expected for your team size is a straight-forward way to earn a higher grade. The flipside, if you have a team member regularly not committing code or committing that code very late in the sprint, is that you should not complete their work for them - if you are concerned about coming up short as a team, add something new so that your teammate still has the opportunity to fulfill their work obligations.

Code quality is the most complex portion of the project being evaluated. To grossly oversimplify, here are some problems/code smells that we will be looking for when grading code quality. Occasionally violating one of these does not mean a design is bad, but this is what you should strive for.

• Long methods (25+ lines)
• Excessive Branching (3+ levels deep in one method)
  
  
• Long classes (100+ lines)
• Low cohesion of a class or method
• High coupling (many dependencies) in a class
• Tight coupling (too much knowledge/use of another class' fields/data) in a method
• Non-descriptive class, field, and method names
• Public fields, properties, and methods that should be private
• Dead code and unused fields and methods
  
  
• Duplicated code
• Magic numbers and strings

In case you're wondering - why these values instead of something else? - the short answer is that these tend to result in code that you'll be able to tolerate for the whole semester. For deeper insight into this, see additional opinions on code quality guidelines