Guidelines for Marking Programming Assignments
There are two goals in assigning a programming assignment in a subject-oriented class (such as EECE 478):
- To help solidify classroom knowledge by providing a context to apply abstract concepts to the execution of a specific task.
- 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;
- 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?
- 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.