OO Programming and Data Structures | CS 241

05 Prove : Assessment Guidelines

Overview

This document outlines the guidelines for instructors and teaching assistants to use as they assess the assignment. It is intended to give structure and guidance to the grading process to ensure that the most important components of the assignment are highlighted, and to promote consistency across sections.

In all cases, the instructor has the latitude to deviate from this rubric on a case-by-base basis to provide the holistic assessment that, in their judgment, best matches the assignment.

Fundamental Concepts

This assignment is designed to highlight the following fundamental concepts:

• Separation of concerns into the correct classes / methods.

• Correct use of composition (HAS-A) relationships.

• Correct interaction with the provided game class.

Scoring

The following categories are used to score this assignment:

/20 - Ball functionality
/20 - Paddle functionality
/20 - Ball class design and implementation
/20 - Paddle class design and implementation
/10 - Point and velocity classes
/10 - Style
----------------
/100 - Total    

Overall Scoring

For each of the categories the following general scoring guidelines apply:

• 100% - Correctly implemented

• 85% - Minor error exists

• 70% - A major error or multiple minor errors exist

• 50% - A good attempt was made.

• 0% - No attempt made.

If necessary, scores in between the above classifications can be assigned.

Examples of Major/Minor errors

Paddle Functionality

• Minor - Does not stop at the screen edges

• Major - Does not move

• Major - Displays at a different place than where it actually is

Ball Functionality

• Minor - Starts/restarts at an incorrect place (or the same place)

• Minor - Starts with constant velocity rather than random

• Major - Does not bounce

• Major - Does not restart

• An attempt made - Ball displays, but does not move

Class design / implementation

• Major - Methods do things they shouldn't (e.g., advance is drawing things or on_draw is updating them)

• Major - Game has been changed to do the things that class methods should do (e.g., move, draw).

• Minor - It works, but better practice requires doing it slightly differently, such as duplication of code.

• Suggestion (but no point deductions) - Duplicated logic in restart and init that could be combined.

Style

In general, the program should use descriptive variable/method names, have class/function headers, and occasional in-line comments.

In addition, the program should make use of constants rather than magic numbers for game parameters (e.g., SCREEN_WIDTH)

Consider the following points associated with these:

• Not using constants for game parameters. -1/-2 depending on how widespread the use is.

• Variable/method naming. -1 for slight problems such as abbreviations that should be spelled out. -3 for more fundamental problems.

  Single variable names are acceptable for a short-lived variable, such as for p in self.products:

• Class/method headers. -2 if missing completely, -1 if many are present, but many are missing.

• In-line comments. -2 if no in-line comments exist at all.