Comp210 Grading Guidelines

For Labbies:

• Clearly, these add up to >100%. The point is, you can do many things wrong, which cause you to lose points. You can't get negative on a particular problem, but you may get 0 for missing three or four of the above items.
• These are guidelines. Do not spend time doing a bunch of arithmetic, calculating 30% of 4 points, etc. Instead, mark things that are wrong, and keep a rough gestalt in your head of how many points taken off, putting down just the final total. You can give partial-points for individual (top-level) problems, but the final score will be rounded up.
• Of course, some problems may not fit the above. If the entire problem is "write a data definition", then obviously that's more than 25%. Moreover, on early assignments we might be stressing the data definitions more than 25%.
• Take off points for things that are wrong or ugly, but not otherwise listed here. (E.g., -1 for atrocious spelling throughout.)
• The sentence "it works" does not merit any points. The point of this class is not to solve the homework problems, but to learn computational problem-solving skills.
• Don't worry overly much about consistency. It's impossible to grade 60 papers and make sure you've graded them all the same, and still maintain sanity. There are many hw's over the semester, and consistent good work will end up with a good grade, despite occasional glitches.
• If there is any extra-credit, list those points seperately.
• Initial the papers you grade.

  For Students:

  First, an explanation of a few items in the guide.
  • "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, #t, #f, 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)]))
    

    (note three things are wrong with this one. Give some space after the word "cond",
    and indent the second argument of the cond-statement at the same point as the conditional,
    not before or after it.)

    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)]))
    
    
    BAD:
        (local [(define (glurble stff)
                (first (first stff))]
           ...)
    (If expression B "(first...)"is inside expression A "(define ...)",
    your indentation had better reflect that.)
    
    GOOD:
        (local [(define (glurble stff)
                  (first (first stff))]
           ...)
    
    
    BAD:
        (map (lambda (x) (cond [(ufo? x) 'area-51]
                               [else     'area-27])) (list 23 'b))
    
    (very hard to find map's second argument, because it's indented as
    if it's part of map's first argument)
    
    GOOD:
        (map (lambda (x) (cond [(ufo? x) 'area-51]
                               [else     'area-27])) 
             (list 23 'b))
    

    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 the Lab Coordinator.

  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 Course Instructors if you are unsatisfied with a grader's explanation.