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.See good example of first four steps here.
Every function must have a comment documenting its input and output types.
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.
Every function needs test cases. Else how do you know it's even working?
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.)
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.
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.