Guidelines for Marking Programming Assignments


There are two goals in assigning a programming assignment in a subject-oriented class (such as EECE 478):
  1. To help solidify classroom knowledge by providing a context to apply abstract concepts to the execution of a specific task.
  2. To provide a context in which programming skills can be refined.
Given these goals, it is important to develop a simple marking scheme that reflects this balance.  I believe that the scheme I describe below addresses this in a way that should be clear and transparent.

The scheme has two significant components;
  1. A percentage grade assessing the conformance of the submitted program to the functional requirements outlined in the assignment text.  In other words, we asked you to write a program that does something: does it do it, and how well?
  2. An assessment of the "means" of accomplishing the task by examining program structure, style, clarity and conciseness.  In other words, assuming that you actually got it to do what we asked, did you do this in a way that is clear and maintainable?
We could just say something like 80% for #1 and 20% for #2, but that seems less than satisfactory for a number of reasons.  The most glaring is that a program that fulfills the requirements, but does so with ridiculous inefficiency and spaghetti code would still get an 80% mark, while a clear, consise program that gets close but doesn't quite fulfill all of the requirements could be graded worse.

Instead, I have adopted a scheme that uses the requirements to establish a baseline mark, and then work down from there in terms of style and clarity of execution.  Think of gymnastics judging in which the difficulty of a routine establishes a base mark (e.g 9.7 or 10.0) and then style demerits are applied to that baseline.

So, we will first assess how well the program functions in terms of the requirements specified in the assignment text. A perfect, bug-free executable will get a 100% baseline (if there are bonus requirements, then these would be applied here as well).  A program with noticeable bugs or that fails to fulfill one or more of the assigned requirements will have a maximum mark less than 100%.  It is very important to program to requirements! Any marks off in terms of functionaliy will be explained with respect to the assignment's stated goals.  If the assignment asks for documentation to accompany the submission, mistakes or anadequacies in this documentation (e.g. the lack of a clear description as to how to invoke the program's functionality) will be penalized as incomplete functionality. After that, this baseline will then be used as a maximum score available only to assignments with clear, concise, easily understood source code.  Poor organization, duplicate code, inefficient implementations, and general bad programming style will then be penalized. Maintainability of the implementation is as important as the functional requirements.

So, your grade will reflect both of these factors.  Perfect functionality will not guarantee a 100% mark, but clear, maintainable code will guarantee that you receive a grade that reflects the functional achievements of your code.  In all cases, the reasons for a grade that is not perfect will be clearly described in the marking feedback. I hope that this makes things clear and you know what to expect.

-- Lee Iverson
September 20, 2004.