All of your projects will be evaluated using the criteria described in this document. Each project will be graded in three areas, the Design Document, the Code and the Execution. Each of these areas are subdivided as indicated below.

The Design Document (40% of project grade)

Program Description: (20%)

This part of the design document describes your implementation. It should briefly discuss the problem that is being solved and then describe the method by which you chose to solve the problem. This is not a line by line description of your program, someone can get that from reading your code. It is intended to be a more conceptual description of the solution (perhaps more of a function by function or class by class description). You should describe (visually or textually) any design methods that you used and the algorithms you selected. If there was more than one possible choice about a given feature, algorithm or implementation method you need to justify your choice. Basically this section tell the reader what you were trying to accomplish, how you did it and why you did it that way.

Test Design and Results: (20%)

This part of the design document describes the tests that you designed, why you selected those tests and how your program performed on the tests. You need to design tests that thourougly test all aspects of your program. In an ideal situation you would test every function for every possible input value. If that ideal is possible and practical you should implement tests that achieve it. Often however, that ideal is either impossible or impractical. In those cases you must carefully select the cases that you will test. In these cases you need to convice the reader that if your program passes the selected tests then there is a high probability that the program will operate correctly in all cases.

Your program code will be evaluated in the following 5 areas:

Modularity: (5%)

Modularity is a measure of how well your program is designed. As the name indicates modularity is related to how your program is broken up into modules. In C++ these modules are functions and classes. Your programs need to make proper use of functions and classes. Each logical component of your program should be divided into its own function. Functions that are related to particular data should be combined with that data into a class. Your selection of classes and functions will determine your score for modularity.

Clarity: (5%)

Clarity is a measure of how easy it is for someone else (i.e. me) to follow the logic of your program by reading only your code. For example, if it is possible to do something with three, difficult to understand, lines of code or with 5-10 easy to understand lines of code you should opt for the 5-10 lines. In this class clarity is more important than minimizing the amount of code. However, if you can get "similar" clarity with 5 lines or with 10 lines you should use the 5 line solution. See elegance for further discussion. Clarity also includes appropriate selection of variable and function names. The names you choose for your variables and functions should be as descriptive as possible without being too long.

Elegance: (5%)

Elegance is a measure of how effectively you have used the available programming language constructs to implement your algorithms. An elegant solution uses the proper programming construct for the problem and uses it in an efficient manner. Therefore, elegance also embodies efficiency. Inefficient code is not elegant. Appropriate use of constants, enumerated types and #define statements can contribute to the elegance of a program.

Examples:

• Using an if clause and an else clause, when possible, is more elegant than using two separate if statements.
• Using massive numbers of if / else if statements when a switch statement will work is not elegant.
• Using a for loop with index running from 1 to 10 then inside the loop subtracting 1 from the index each time it is used is not elegant. A better solution would be to use an index of 0 to 9.
• Using multiple loops when the operations performed could be combined into a single loop is inefficient and thus not elegant. Note: this may sacrifice a bit of clarity but that can usually be compensated for by effective use of comments.
• Hard coding a value such as the maximum allowable number of entries in an array in many places in a program instead of using a #define or constant value is not elegant.

Often you will find a tradeoff between the elegance of your code and its clarity. You need to ensure a proper balance for the particular type of program on which you are working. For example, if you are writing an Operating System you will probably favor elegance over clarity to gain increased speed and efficiency. However, if you are writing code that is likely to be read and modified by other programmers then clarity may be a better choice. Elegance is important but do not completely sacrifice clarity for elegance in this class.

Comments:(5%)

Use comments liberally to explain the logic of your code. Every program file must have a comment block at the top containing your name, the filename and a brief description of the file. Every function must have a comment block at the top indicating the purpose of the function. A function's comment block must also identify all parameters and their expected types and values. A function's comment block must also identify any effect that the function has, its return type and any changes to reference parameters or global variables. You are also encouraged to use comments within your functions to explain your logic.

Format:(5%)

Format is a measure of how well your code is laid out on the page. Use consistent spacing, indentation and {} location. Also, use blank lines and comments to separate logically distinct sections of your code. You can use a style similar to what the book uses, similar to what I use in class or some other style. However, if you invent your own style you need to make sure it is easy to read. Your spacing, indentation and {} location must be consistent and must emphasize the structure of the program. Format also includes your naming scheme for variables and functions. I suggest the following:

• Constants & #defines - use all caps. and separate words with underscores.
  
  Example: const int MY_CONST;
• Variables - use all lowercase letters and separate words with a single capital letter.
  
  Example: int myLuckyNumber;
• Functions - start with a capital letter and separate words with a single capital letter.
  
  Example: int MyFirstFunc(int theParameter);

Your program execution will be evaluated in the following 2 areas:

Correctness: (15%)

Correctness is a measure of how well your program performs the required task. If your program does not solve the required problem it will get a low correctness score. On the other hand if your program does solve the problem it will get a high correctness score. However, note that there are lots of other criterion that I am looking at. Therefore, a program that gets the correct answer does not guarantee that it will get a high overall score.

Interface: (15%)

The interface of your program is how it presents itself to the user. It includes how the program displays its output and how it accepts it input. The output should be nicely formatted and should make it clear what the user is seeing. If you users are used to seeing a particular type of information displayed in a particular format then your program should display it in that format as well. Input should be requested in a way that looks nice and makes it clear what input the program is expecting. The program must also handle unexpected input in a reasonable way (NOTE: Crashes and infinite loops are not reasonable.)

Examples:

The value of PI is: 3.1415927

-vs-
3.1415927

Enter a number [0..10]:

-vs-
?

This is a totally qualitative evaluation made by me. After grading all of the projects in all of the above areas I will go through them and assign an overall impression grade. The more outstanding a project is the better its overall impression grade will be. An exceptional interface, design document or testing strategy are examples of things that can make a project outstanding.