Computer Science 132
Introduction To Computing II

Dickinson College
Spring Semester 2000
Grant Braught


Program Design and Style Guide


All of the programs that you write will be evaluated according to the following guidelines:

Program Design

Your program design will be evaluated in the following 3 areas:

Modularity:
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 Java these modules are methods and classes. Your programs need to make proper use of methods and classes. Each logical component of your program should be divided into its own method. Methods that are related to each other and to particular data should be combined encapsulated into a class. Your selection of classes and methods will determine your score for modularity.

Clarity:
Clarity is a measure of how easy it is for someone else (i.e. me) to follow the logic of your program. 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:
Elegance is a measure of how effectively you have used the programming language constructs available to you. 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.

Examples:
Elegance is important but do not sacrifice clarity for elegance in this class.
Program Style

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

Format:
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 should use the style that I use for all of our examples. This is the same style that the book uses.

Format also includes your naming scheme for variables and functions. The following is the scheme we will use for naming:
Comments:
Every class file must have a comment block at the top containing your name, the filename and a brief description of the file. Every method must have a comment block at the top indicating the purpose of the method. A method's comment block must also identify all parameters and their expected types and values. A method's comment block must also identify any side effects that the function has, its return type. You are also encouraged to use comments within your methods to explain your logic. Do not use comments to simply restate what is obvious from the code: (e.g. x=a+b; // Add a and b.)

The program style points are easy points if you just take the time to make sure you do what is asked.

Program Execution

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

Correctness:
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. So getting the program to work should not be your only goal in completing a lab.

Interface:
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 its input. The output should be nicely formatted and should make it clear what the user is seeing. 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: