CS1102 (A12): Accelerated Introduction to Program Design

Homework Grading Rubric

In this course we teach you to code using a six step sequence we call the Design Recipe. It is a generally good way to program, especially if you do them in order, since each section helps you get the next section right. The TAs will use the Design Recipe as a framework to give you help during office hours, and it is also our reference when grading.

STEP ONE - Contract (3 points)

Every function must have a comment documenting its input and output types.

• -1 for each type that is inconsistent with the function definition
• -1 for a truly terrible function name
• -3 if the contract is missing entirely

STEP TWO - Purpose statement (3 points)

Every function must have a comment describing what the inputs mean (if the first argument is a number, is it a height, a speed, something else?), and what the function compute from these inputs.

• -1 if the description of the input doesn't match the problem statement
• -1 if the description of the output doesn't match what the function does
• -2 for a vague purpose statement, or one that shows confusion about what the function should be doing
• -2 for omitting part of the functionality
• -3 purpose statement is missing entirely

STEP THREE - Data definitions (10 points per definition)

• -1 for a DEFINE-STRUCT whose field order doesn't match that in the type comment
• -1 for unknown type names in the type comments
• -3 (up to) for poor choices of which fields to include (irrelevant info, wrong level of detail, etc)
• -5 (up to) for no examples of the data, or too few
• -5 (up to) for mistakes in the commented-out template
• -10 If a program uses an undocumented form of data (only deduct this once in an assignment for the same missing data definition)

STEP FOUR - Test cases (10 points)

Every function needs test cases. Else how do you know it's even working?

• -2 for each untested branch of a COND, up to 10 points total
• -2 when the input to this case is wrong.
• -2 when the expected result of a test case does not match the problem statement
• -3 when the expected result of a test case is missing (for images, expected answers can be descriptive strings)
• -2 if there is a bug in the program that isn't caught by any test case
• -3 if test cases aren't executable Racket code

STEP FIVE - Templates (10 points)

Functions must follow templates rules. Your code should follow the "one data definition, one function" rule, and the structure of the function must follow from the structure of the data it's operating on (some exceptions are made for posn and very simple functions like accessor on nested structures.)

• -4 if a data definition has two cases and the COND has 3 (should have been an inner COND)
• -6 if the recursive call that the template would have given for free is missing
• -7 if there is a missing template function
• -10 if there's nothing resembling the template structure in their code

STEP SIX - Program logic (20 points)

The last section is for all program errors that do not come from the templates. We take off 2-10 points, depending on the of severity the problem.

• -2 for really small errors (like using * instead of +)
• -4 if the logic is on the right track but the code doesn't tie things together quite right (for example: using a struct selector backwards)
• -5 for premature optimization
• -5 for code duplication (needs a helper function)
• -10 if the logic is about halfway right: some okay and some a bit off
• -16 if the logic doesn't make much sense
• -20 if the code doesn't really go beyond the template

The grading rubric applies to every function in your program. Every function must have contract, a purpose statement, some tests, etc., even if it's brief. Your overall mark on the homework will be the application of the rubric above to each function you wrote, plus some question-specific points at times. Then the whole thing gets re-scaled to 100 points by putting more weight on the harder parts of the assignment.

About testing: Students often ask if they have written enough tests? For the homeworks in this class, you must test your function sufficiently to convince us that you have reasonable grounds to believe that your function is correct. Saying, "I have ran my function many times in the interaction window", or "obviously this function is correct" is not convincing. At the strictest minimum, you must hand in two tests for every function (for very simple functions); many of your functions will need more. Test the edge cases and make a real effort to find the bugs in your code. Additionally, unless explicitly relaxed in a specific homework, we require that your tests achieve complete execution coverage. That means that every function in your code must be executed at least once by your tests.

DrRacket helps you confirm that you have acheived complete execution coverage by highlighting (in yellow or black) which parts of your code were not executed each time you click Run. If you have such a highlight, add a test to execute that part of the code. To get full marks, your homework submission must run without crashing (obviously) and have no highlights after running.

About helper functions: Sometimes, the best way to implement the function we asked you to write is to break out a small part of it into a "helper function." The book discusses the situations when you might want to use a helper function in Chapter 3. These helper functions should also have their own contract and purpose statement, but testing them is different. Sometimes you can get complete coverage for helper functions simply by running the tests for the main function. Testing your helper functions this way in your homework submission is fine. So long as you have complete coverage you will get all your points. However, keep in mind that testing helper functions on their own is sometimes the fastest way to debug them.