...
- 40% on following the process and the documentation guidelines described by the design recipe. This includes things elements like data definitions, templates, contract, purpose, examples, and tests.
- 30% 20% on code style. By style we primarily mean that your code follows closely what is dictated by the recipe. But style also includes presentation (correct indentation, choosing good names for variables) and design (using reasonable auxiliary functions, avoiding code duplication, defining helpful constants).
- 30% 40% on correctness. If your program is correct, you will get all of these points. If not, you may get partial credit depending on how many of our unit tests your program passes. If you make a serious mistake, you will probably receive zero correctness points.
...
Some problems ask students to demonstrate the step-by-step process of reduction from an expression "hand-evaluate" a program expression, reducing it to a value. Where possible, this should be answered with a sequence of runnable Scheme expressions, each of which resolve to the same result. In some cases, you may need to comment out your duplicated code. In these problems, the solution is correct if it follows the definitions outlined in the text, and it doesn't skip important steps (everything is "important" unless the instructions say otherwise)*. Follow the examples given in the Scheme HW Guide and include every step. Within an expression, you may elide subexpressions if there contents are obvious from conte3xt. Deductions will be made based on how far "off track" a reduction is.
...