Coding Style
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 Scheme or having learned Scheme 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 (
parse
comes to mind) and in that case recommend that each match case fits on a screen. - Assume that your reader understands Scheme, so, in any inline
comments, explain why you wrote the code, don’t explain
what you wrote. We consider
define-type
to be self-documenting. - Only use Scheme primitives that we have taught in this course. For
example, use
first
andrest
instead ofcar
andcdr
. Likewise, consider usinglocal
instead oflet
(local
is much better, anyway).