next  up previous
Next: About this document ...


How I Grade Programs

Principle: it's got to work robustly (be sound, phenomenologically) and be well-built (be sound, ontologically). That is, I must not be able to break it, when I play by the rules of game, then I have to be impressed with how you constructed your solution. I stop grading once I have determined a grade. 
I start with a black-box approach; one that is based only on the performance of the software. I do this by generating some ``easy'', ``medium'' and ``hard'' test cases which I feed to the program. After the tests are complete, I read the program.

Compilation

I compile the program.1 If I can't get it to compile, it has earned an F. This is the same as a no-submit, for you might as well have submitted nothing.

Execution

I run the program with no arguments, to see what happens or if there is a ``usage is''. This message should be in terms of argv[0], not some string that you pick. Core dumps are not acceptable here.
It the program passes the ``easy'' tests, it has earned a D. If the program cannot pass these simple functional tests, I don't even bother looking at the code. The program has earned a F. Look at it this way: it complies but does little or nothing else.
So, to earn a D, the program must compile, not core dump on 0 arguments, and pass the ``easy'' tests.
If a complete set of ``medium'' tests is passed, it has earned a tentative C; that is, it has achieved the objectives and performed acceptably. I run the ``hard'' tests. If all is well, it has earned a tentative B.

Construction

I now move to code inspection, a white-box approach; I look to see how well built it is.
Depending on the quality of the solution, the grade can go up and entire letter or have a ``-'' attached to it. For example, a program that passes the hard tests, but is a disorganized hack earns a B-; a program that passes the ``medium'' tests, but is beautifully written could go as high as a B, but will more likely earn a C+ or B-.
 Software quality, which is not determined by the number of comments, is discussed in another document.



About this document ...

next  up previous
Next: About this document ...
2000-08-14