Breutzmann's General Criteria for Program Grading

Programs are typically graded in four areas using the acronyms: W-UI-S-M, standing for: Works, User Interface, Style, Modularity. These may not all apply to all programs. Modularity in particular may only apply after functions are covered. In general, "W" asks whether the program meets design specifications, i.e., meets input specifications and produces correct output. "UI" indicates whether the user interface (text or graphical) is informative, accurate, aesthetically pleasing and easy to use. "S", asks whether the style of the code is easy to read and understand and follows the course specifications. Finally, "M", modularity, asks whether functions, methods, classes, modules and class/global/local variables are appropriately used. A typical percentage break down is 50%-15%-20%-15%.

The following are typical of the criteria used to grade programs. Students need to be aware of any assignment-specific requirements.

Works: Non-working programs are usually returned for fixing with an appropriate penalty. It is better to hand in a working program late than a non-working program on-time.

• The program compiles and runs on an acceptable platform in an acceptable language (usually python or Java in the appropriate Science Center computer lab).
• The program accepts legal input as specified in the problem description. [see UI for illegal input]
• The program produces correct output for legal input as specified in problem description. [see UI for labeling etc.]

• Introduction: the program displays an introduction giving the purpose of the program and explaining any concepts not obvious to the average user.
• Layout: the information looks neat and clear on the screen or in the graphics window. It is easy to read and interpret. The program achieves this through appropriate use of:
  • blank lines to separate sections and ease reading,
  • proper English grammar and spelling,
  • a clear separation from previous and subsequent lines in the shell window,
  • having graphic elements laid out in an easy to read and understandable format
• Input: is prompted in an unambiguous manner making units and expected input formats clear.
• Illegal input: is caught and handled appropriately. (as far as techniques for this have been covered previously)
• Output: is easy to locate, read, and properly labeled, including units when appropriate.
• Repeatability: is achieved so that the user is allowed multiple runs of the program without having to rerun the program.
• Unnecessary input is minimized, eg, extra clicks and returns.

• Initial documentation block:
  • identifies team members,
  • identifies course, semester, and year,
  • describes the purpose of the program including an explanation of any terms unfamiliar to a typical reader of the code. (e.g. epact),
  • identifies sources of assistance other than the instructor, course materials and team members.
• At each function/class/method documentation is present to:
  • identify the purpose of the class/function/method,
  • identify the role of each parameter (descriptive variable names help here)
  • identify preconditions(formally or informally) (assert can be used to check simpler preconditions)
  • identify postconditions (formally or informally) and return types/values unless unambiguously and clearly described in the purpose clause
• Readability is improved through the appropriate use of the following elements:
  • descriptive variable/class/function/method names,
  • white space and comments to logically separate and identify sections of code,
  • indentation to show structure (free in python!).
• Additional comments:
  • to explain difficult algorithmic elements.
  • to identify the sources of non-original code elements

• The project is conceptually broken down into appropriate smaller logical units.
• Information is passed from component to component through an appropriate use of parameters and return values.
• Global variables are used sparingly and appropriately.
• Program elements are designed with an eye to reusability