Program Evaluation Criteria

Programs will be evaluated based on the following criteria:

Correctness:

The program should give correct output for all reasonable input. Make sure that you test for `boundary' cases as well as ordinary cases.

User-friendliness:

The program should handle errors as gracefully as possible, and it should display clear instructions and prompts to assist the user in entering appropriate input.

Documentation:

Include at least the following:

• a heading with your name and the purpose of the program.
• for each function, a statement of what that function does.
• any extra commentary that is needed to explain unclear parts of the program.

If your solution is complicated or unusual, feel free to include an extra sheet of paper with words or diagrams that explain what your algorithm is.

Readability:

In addition to comments, the program should use mnemonic variable names, indentation, and so on, to make it easy for a human reader to tell what the program is doing. (A readable program puts the grader in a good mood!)

Elegance and efficiency of the solution:

The program should solve the problem in a logical sequence of steps, without wasting unreasonable amounts of storage space or computing time.

A perfect score can only be earned by a perfect program, and very few programs qualify!

The course catalogue describes a grade of `A' as `excellent'; an `A' can only be earned by excellent work.

Many otherwise-good programs lose points because the students did not test adequately. Understand that I am going to test the boundary cases and invalid input cases. Examples of what I will test may include giving a mathematical program negative numbers (are you taking square roots?) or zeros (are you dividing?); giving a trigonometric program right or obtuse angles; giving a text-based program a name consisting of all spaces, or a name 43,000 characters long, or a name zero characters long. Your program will have to behave correctly in any of these cases. If it's possible to do something useful, it should be done; if the program can't continue at all, then it should warn the user about invalid input and give some kind of instructions about what to do next. Programs should not merely crash on invalid data.

Some of these considerations will be waived in certain cases, most often for lower-level classes (such as Introduction to Programming) or where we are using a language which is weak at some kinds of tests. But unless specifically stated otherwise, assume that your programs have to be robust and will lose points if they are not.

Spelling, punctuation, and grammar all count!