CIT 591 Grading Criteria
Fall 2009, David Matuszek

Every assignment is different, so the detailed criteria for every assignment are different. In general, though, we grade on two things: Function and style.


Read the assignment. Carefully. Then do what it says.

The biggest cause for losing points is failing to read the assignment carefully, or not taking it seriously. The assignment says what the program should do, and if it does something different, you'll lose points. It's that simple.

Sometimes you see movies that are "based on the title of a real book." Sometimes I see programs that are "inspired by the title of a real assignment." Programs like that don't get high grades. Most of the points we take off are of the form, "[We said to do X, and] you didn't do X."

Now having said that, let me add that I'm delighted when you do what the assignment says, and more. There's a big difference between doing "something like" what the assignment asks for, and meeting the requirements and then adding extra features.

I can't always think of every possibility when I write an assignment. If I fail to specify something that seems important, bring it to my attention. If I don't tell you exactly what functions to write and what messages to print out, then it's up to you to do something reasonable.

Syntax errors

You wouldn't deliberately turn in a program with syntax errors. But here are a couple of things you might do:

Runtime errors

If your program crashes when we use it, chances are you didn't test it carefully enough.

Another possibility is that your program is "fragile"--you have to do exactly the right things, in the right order, to make it work. If your program has a main function, it probably takes care of that. If the user has to call function X before calling function Y, or the program crashes, then you have a problem that needs to be fixed.


Since thorough testing is required in most assignments, you will lose points for inadequate testing, even if your program works. So test thoroughly. Remember, the purpose of testing is not to "prove that the program works," but to show where it doesn't. Find all the errors you possibly can, and fix them. If you miss some, chances are we'll find them and grade the program accordingly.

Unit tests should test each method by itself as much as is reasonable. This helps expose fragile methods that depend too much on other methods to set things up for them.

In many ways, TDD (Test Driven Development/Design) encourages better programming style.


Good style is what makes a program readable. That's key. If it's readable, then its understandable, modifiable, testable, and debuggable. Style is important!

I talk a lot about style as the semester progresses. You aren't expected to follow the style rules I haven't told you about yet, so the requirements get more stringent as the semester progresses. Here are the Style Rules that I have talked about in class.

The convention for this class is to use "camelCase" for naming variables and functions. For example: flashCards, createCodeArray.