Grading Criteria
Does it work?
At least half of your assignment grade will be based on your
program(s) performance. Your programs should compile without warnings
or errors and perform correctly during the demo in the CAS cluster.
Program performance will be tested using a standard test suite
generated by the grader and professor.
Is it efficient?
In addition, your code should not make needless computations that
would make the graphics program slow. A classic embodiment of this
philosophy is moving computations outside of an inner loop whenever
possible.
Does it conform to the programming conventions?
A considerable portion of the credit will be given for following
the
programming conventions detailed below: informative comments, good
programming style, and general presentation.
Programming Conventions
This is a compulsory set of programming rules to
foster the habit of following some convention consistently.
These conventions are designed to improve code readability, on the
premise that far more human time is spent reading code than writing it.
Names
As part of program documentation, names must clearly indicate the
function and type of the named object.
For instance, you can use multi-word names for functions and
variables that describe what their purpose, e.g., insertAfterElem
().
Constants are usually defined using all caps, e.g., MAX_ELEMENTS.
Never use acronyms as abbreviations, instead, you may
eliminate vowels (e.g., Elmnt
), or use an
unambiguous prefix (e.g., Elem
). This
makes it easier for someone else to read and maintain your code.
Indentation
Maintain consistent indentation throughout your code.
Examples,
if (condition)
{
...
}
else
{
...
}
for (...)
{
...
}
Comments
Comments should help the reader of your code to understand it, and they
also convince the grader that you grasp the what, how and why of your
code (as opposed to having hacked it into working).
Like any other form of expression, it should not be flowery or
repetitive.
Avoid comments that simply rephrase your code in English, without
summarizing it or adding any information.
Before each major section of the program, give the purpose of
that section. Before each function in the program, describe the
function and give the inputs, output and error conditions of the
function. For each variable, give a one line comment stating the use of
the variable. All internal documentation must be written in English,
not in a computer language.
Standard Boiler Plate
Each source file must have a standard "boiler plate" at the top. This
boiler plate must include your name, the class, the
assignment number, due date, the problem number, and a brief
description of the what the code in the file does. You should outline
the method you used to solve the problem, describe of the variables
and data-structures used in the program, any error conditions which
might be encountered in the solution, and how these error conditions
are handled by the solution. Your boiler plate MUST include what the
inputs are and what the output is, and should be in (short) paragraph
form and in standard English.
Avoid Global Variables!
Before you use global variables, consider first supplying pointers to
variables so that functions can modify those variables by dereferencing
the pointers.
If that is not enough, then try static local variables, and, failing
that, static global variables.
Only when none of these work--a very rare event indeed--should you
resort to plain global variables.