Note that the very first homework is too simple to have most of these issues, so don't worry about these right away.
These guidelines are rough. Certain instances may have a higher or lower penalty at your discretion. If you're not sure about how to grade, send email to the Lab Coordinator. Overall, grading will be strict; 85% will probably be a decent score, and a 100% will be rare.
If appropriate, give | ||
- data defn | -25% | |
- examples of data | -25% | |
- template | -30% | |
Use helper functions (see below) | -50% | |
Every function needs | ||
- contract | -10% | |
- appropriate use of types (see below) | -10% | |
- to follow template for type | -30% | |
- ... or document choice of recipe | -30% | |
- test cases | -25% | |
- consistency of code and tests | -100% | |
- good formatting | -100% | |
- no magic numbers | -10% | |
Papers must be stapled | -10% |
"Use helper functions" is a matter of taste. The sin is to feel that you have to do everything in one big function -- that is no way to decompose a problem into simple parts! As a rule of thumb, a Scheme function shouldn't be more than ten lines or so of code, and will usually be five to six lines of code. As a general rule, if you are thinking in your head "these three lines compute the fluttershushanuff", then pay attention to the fact that your own thinking gives "fluttershushanuff" its own name; why not reflect that in your program? It's not unusual to have many small one- and two-line functions, just because they are obviously their own task.
"Appropriate use of types" means (e.g.) using booleans for yes/no values,
rather than using 0 and 1, or 'yep
and 'nope
.
Later in the semester it includes using structures as needed. Overall,
this point is not a big issue in Scheme.
Magic numbers are constants hard-wired in the code. There
are a few good constants that may appear inside of code: 0, 1,
true
, false
, and empty
.
All others should be given a name. For instance, using "80 (mph)" should
be given a name like CRUISING-SPEED
.
The test cases must show that you covered all bases (see recipes).
A test case includes, in one way or another, the result that your function produces. If we discover a discrepancy between the code and the implied result, you lose all credit for the problem.
If your function returns an incorrect answer, please note this in your comments. (Do not elide that test case from your homework, and hope we don't notice!) It is better to state what bugs your function has, than to claim the code is correct when it's not; we will grade accordingly.
Make sure to indent properly. DrScheme does all the indenting for you (except line-breaks), and there is a menu option: re-indent all. Indentation should help the reader understand your program. Some examples:
BAD: (define (foo a b) (cond[(zero? a) (extremely-long-function-name a b)] [(positive? a) (even-longer-than-the-extremely-long-function-name a b)])) GOOD: (define (foo a b) (cond [(zero? a) (extremely-long-function-name a b)] [(positive? a) (even-longer-than-the-extremely-long-function-name a b)]))
Put space after key words like cond
.
Align similarly-nested parts like the conditional's clauses
and each half of each clause.
BAD: (local [(define (glurble stff) (first (first stff))] ...) GOOD: (local [(define (glurble stff) (first (first stff))] ...)
If expression B "(first...)" is inside expression A "(define ...)", your indentation had better reflect that.
BAD: (map (lambda (x) (cond [(ufo? x) 'area-51] [else 'area-27])) (list 23 'b)) GOOD: (map (lambda (x) (cond [(ufo? x) 'area-51] [else 'area-27])) (list 23 'b))
Again, align similarly-nested parts similarly.
Here, it's very hard to find map
's second argument,
because it's indented as if it's part of map
's
first argument.
In general, either put a function's arguments all on one line (that's fine), or indent so that they're all on separate lines. If you are ever in doubt or want more examples look at the book, class notes, or even write it out in drscheme to see how general formatting should be done.
Keep in mind that your labbies are grading a large number of papers, and sometimes mistakes are made. If you feel something was marked off even though it was correct, by all means check with the grader. However, if you feel that the grader was correct in taking off some points, but you feel they took off too many, try to defer to their judgement. If you feel that you've been graded overly-harshly consistently over several homeworks, first see the grader(s). If they don't agree, see an instructor.
Disclaimer:
This guideline is not binding;
we reserve the right to give whatever score we feel is fair.
Guarantee:
You have the right to question any score, and get an explanation
of why we feel it is fair.
See one of the instructors if you are unsatisfied
with a grader's explanation.