RAIK 183H

Handout 1: Programming & Grading

August 25, 2009

As outlined in the Syllabus, programs that compile and run will be graded as follows:

45% Program Correctness,

15% Software Design,

10% Programming Style,

15% Testing, and

15% Documentation.

Here we give some examples and guidelines on what we expect of each component.

Program Correctness

This refers to (1) whether and how well the program meets the requirements specified in the assignment, (2) how well the program addresses the problem specified in the assignment, and (3) whether and how logically correct the solution is. It is possible that your code may yield incorrect results with logically correct solution to the problem specified in the assignment. It is also possible that your code may yield correct results with logically incorrect solution to the problem specified in the assignment.

Software Design

This refers to (1) whether good Object-Oriented Programming strategies are used properly – modularity, class hierarchies, polymorphism, overloading, etc., and (2) whether the overall software organization is clear and sensible, including the program file naming convention and data file naming convention. A solution that gives correct results may be poorly designed. For example, you may create two separate classes: UndergraduateStudent and GraduateStudent. These two classes may end up sharing a lot of data members. A better software design is to create a superclass: Student, and then create two subclasses, UndergraduateStudent and GraduateStudent for code efficiency.

Programming Style

This refers to (1) good and clear indentations (e.g., a tab or at least three spaces for an indentation), (2) good use of variable names (e.g., numberOfStudents is better than x), (3) proper declaration of global constants, (4) efficient use of methods (functions & procedures) to prevent redundant coding, (5) adequate length of each method (functions & procedures), and so on. You should see a lot of good examples of good programming style from our textbook. The consistency of your programming style throughout your code is also extremely important. It allows readers of your code to understand your code much more easily. Our textbook provides a lot of pointers on good programming styles.

Testing

This refers to our testing of your program, using our own input data file and matching your output to the correct output. Boundary conditions will be tested to see whether your program can handle those conditions. For example, suppose that your program reads an input integer from the screen and processes it. Will you program still function if instead a real number is entered?

Documentation

This refers to all the good practices that one should practice: header documentation (program and methods) and inline documentation. One should also use Javadoc. Since we will cover this in our laboratory, I will not elaborate it here. But a good documentation should describe (1) what the code does, (2) how the code achieves what it wants to do, and (3) at times, why the code uses a particular solution strategy.