How to maximize your program grade in CSC270H, Summer 2001

Your program will be graded on two factors, correctness and programming style.

Program correctness

Your program will be automatically compiled and run against test data sets. There are several important points.

Your program must compile.
A program which fails to compile will get extremely poor marks.
Your program must run.
This means that your program must not crash. A program that crashes every time it is executed will score as poorly as a program that does not even compile.
The program must be able to handle errors.
This means you must consider the possible conditions that can cause an error and either write your code so the error can not occur, or if an error is unpreventable, handle it. A general method of handling errors is to detect the error, print an error message, and exit the program. Letting the program crash with a segmentation violation is not a good way to handle errors.
The compiler should not give any warning messages when compiling your code.
This is not as serious an error as the above three, but it will result in points lost. Be sure to compile your code with the command
```
     gcc -ansi -Wall
```
If these compiler flags produce no warning messages, you are ok.
Your program should give correct responses.
Read the problem description carefully. Does your output correctly match the specifications of the problem? Have you considered all possible cases?

To get a passing grade, your program must at least meet the first two requirements: it must compile and run without crashing.

What if I can't get my program to work?

Sometimes it happens that your program will have a bug which either prevents it from compiling or causes it to crash, and you can not figure out how to fix the problem.

Hopefully you can isolate the area of the code which has the bug. Now you are left with a dilemna. If you include this code in your submission, your program will not work at all, but if you omit this code, you will not get any partial credit for the hard work you put in.

The solution is to bracket the problem code with:

#ifdef DOES_NOT_WORK 
#endif /* DOES_NOT_WORK */

These compiler directives will block the code which appears between the #ifdef and the #endif from being compiled or being run. (Note: you must NOT have a #define DOES_NOT_WORK anywhere in your code!)

It is important that you bracket the problem code carefully. The rest of your program must work without this bracketed code. The goal is to have the program output as close as possible to the correct answer.

For example, suppose the problem asks you to sort your output, but your sorting function is crashing. The solution is to bracket your sort function definition and function call with #ifdef DOES_NOT_WORK and #endif. The result will be a program that produces correct output but does not sort so you will get close to full marks on correctness. Also, you will receive credit for your sorting routine when we examine the printout.

How do I test my code?

Good testing of code is a learned skill. Generally, you need to look at your code and think of what types of data may cause it to fail and then test your program on that data. Generally, there are four types on inputs you must test.

Legal values: Does your code correctly handle the types of values you expect?
Illegal values: Does you code correctly deal with incorrect values?
Boundary values: Consider the values which are legal, but close to illegal. Does your code correctly handle these?
Special cases: If you have cases in your program to deal with special values, you must test each of these values.

Program style

The programming style of your code will count significantly to your grade. Simply getting your program to run correctly is not enough. Your code must also be simple, easy to read, and easy to understand. A short elegant solution will receive a higher grade than a long, convoluted solution. Please follow the style guidelines. Some key points are as follows.

Comment your code.
No comments will yield a significant loss of points, but avoid too many comments that clutter your code. Good commenting is a skill that you learn with practice.
Use procedures.
Break up large programs into small procedures. The procedures should encapsulate individual operations of your program. For example, if you need to compute the factorial of a number, create a separate function for the operation.
Use descriptive names.
If you have a procedure that computes the factorial of a number, call it factorial not helper_proc. The same goes for variables.
No magic numbers.
Organize your programs as follows:
1. include files
2. defines
3. typedefs and structure definitions (if any)
4. global variables (if any)
5. function prototypes
6. main
7. all other functions
Always indent.

Click here to go back to the menu, if your browser does not support frames.