Program Assignment Guidelines


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.