20% of your grade for programming assignments will depend on your design, style, and comments. Since we expect that you document and test your code anyway, we think of this as giving you a free 20% for each assignment.
Not already knowing Racket or having learned Racket with a different style are not excuses for not following these requirements. We are using the coding style from HtDP for this course.
- All functions must have a purpose statement that fully explains, in a sentence or two, what the function does.
- All functions must have contracts.
- If you need to use a new type, define a new datatype to represent it. Do not overload lists. Understand the difference between lists and datatypes. Lists are homogenous collections of unlimited extent. In contrast, datatypes are heterogenous collections with a fixed number of members.
- As a general rule, all functions should be no longer than
what fits on a screen. We will of course relax this for
functions with a lot of pattern matching (
parsecomes to mind) and in that case recommend that each match case fits on a screen.
- Assume that your reader understands Racket, so, in any inline
comments, explain why you wrote the code, don’t explain
what you wrote. We consider
define-typeto be self-documenting.
- Only use Racket primitives that we have taught in this course. For
cdr. Likewise, consider using
localis much better, anyway).