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 CGL 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.
Multi-word names, for entities other than constants, should have every
word other than the first one capitalized, e.g.,
insertAfterElem
.
Never use acronyms as abbreviations, instead, you may
eliminate vowels (e.g., Elmnt
), or use an
unambiguous prefix (e.g., Elem
).
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 C.
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 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.