All three project phases will be graded according to a 0-100 point scale. The correctness of your solution and the style/clarity of programming will weigh equally towards your score. Late assignments will have 5 points deducted for each day that they are late (including weekends). Consequently, you are encouraged to turn in a nearly correct program on time rather than spend a few additional days perfecting it.
The following principles will be used in grading programs. The first two items have to do with style, and the final item deals with correctness. It goes without saying that a program that does absolutely nothing correctly but has good style is not worth much.
This is meant to convey overall grading policies for the assignments. For specifics and deliverables, see the Phase 0 document, the Phase 1 document, the Phase 2 document and the Student Manual.
Global structure: The file structure should conform to the description given in Implementing Modules in C.
Structure within files: The order of includes, declarations and definitions should follow the one given in Implementing Modules in C. Your programs should be properly indented. Use The C Programming Language by Kernighan and Ritchie as a guide for this. Use white space (blank lines) to separate groups of related (conmmented) statements. The various sections of a file should also be separated by white space.
Constants: There should be no constants embedded in your code. All constants should be given mneumonic names using the #define mechanism and references to them should be through these names. Here, we do not mean
#define FIVETWELVE 512
but rather
#define PAGESIZE 512
The only allowable exception to this rule is the use of the constants 0 and 1.
Every module should have a header comment as follows:
Description of the data structure (or abstraction) implemented and maintained by the module.
The module invariant. This states (in terms of the module variables) what remains true throughout the execution of the module by calls to its externally visible functions.
A brief description of how the module implements the stated abstraction.
Every function (externally visible or local) of the module should have a header comment that describes what the function does.
In commenting the code, use a comment for a block of statements. Here, we do not mean C blocks ({ ... }), but groups of related statements. Think of your functions as you would sections in a book or report. In a book, a section is broken into smaller pieces (i.e. paragraphs). Likewise, a function has smaller related sets of statements. These should have appropriate comments aligned with the indentation level of the statements to which they apply.
Each clause of an if statement should have a comment to clarigy the condition under which the clause is executed.
Many variables of a program or function have meantings that remain unchanged (invariant) with execution. The declaration of these variables should always be commented by including a brief statement of their meaning on the right side of the same line.
Declarations of variables used in different contexts or used only to hold temporary values need not have a comment. Use of names such as "temp," "i,", "k," etc. for them will relay this fact.
Try to strike a balance between undercommenting and overcommenting. A well-commented program is not one that has a comment for each line of code. Do not construct comments that simply restate what is obvious from the code. For example, the comment "assign zero to p" is useless when referring to the statement "p=0." Your comments should be a high level description of what is going on.
The following aspects of correctness will be considered in computing project grades:
Incorrect initialization.
Program or function does not follow the required specifications.
Program or function does not handle special cases. You should make no assumptions about the valid range of input data to a function unless it is stated in the specification of the problem. The entire possible input data range should be handled in some reasonable manner.
The program or function does not correctly execute the given test cases (user supplied for phase 0, given in test.c for phase 1 and 2). The test cases may reveal violations of 1, 2, or 3.
Inefficient implementation.