[ HOME ]
 
Grading Guidelines

For TA's/Graders:

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, see me.

If appropriate, give   
- data definition -25%
- examples of data  -25%
Use helper functions (see below)  -50%
Every function needs   
- appropriate use of types (see below)  -10%
- document choice of recipe  -30%
- good formatting  -100%
- no magic numbers  -10%
Every top-level function needs  
- test cases -25%
- consistency of code and tests -100%
Papers must be stapled  -10%
  • 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 or formatting.
  • 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.
  • Try to be consistent. However, realize that it is impossible to grade 50 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.
     

For Students:

A solid understanding of the homework material is critical for the exams. If you don't understand how to do the homeworks, you will not understand.

  1. Solve each problem on your own.
  2. When a homework asks for hand-evaluation, make sure
    • to include the requested steps
    • to arrange them in a neat and proper manner
    • that DrScheme evaluates intermediate expressions
    •  ... and that the answers are the same. (Otherwise you made a mistake.)
  3. When a homework problem asks for a program,
    • formulate the necessary data definition(s)
      or point to some other problem on the same homework set
      or point to a page in the Book.
    • show with examples what the function is expected to produce for sample inputs; you may wish to add comments that explain how to get from the input to the output;
    • define the program
    • for top-level assignments or even complex intermediate functions, include tests.

  4. Format code properly. You must read code in the book to learn when to introduce line breaks. If you use line-breaks properly, DrScheme can assist with the rest. Typing return places the cursor at the proper spot on the next line. You may also use the Indent choices under the Scheme menu to format programs.

    Use DrScheme's block comments #| ... |# to include supplementary material, like the data analysis, program examples, etc.

    Neat work is likely to be good work. Ugly work is bad work.  Part of the focus of this course is to move you toward Software Engineering with large programs and multiple programmers. To ensure that you acquire a proper taste for indentation and presentation, we will assign F's for ugly homeworks, i.e., homeworks that significantly deviate from the norms set by the code in the Book.

  5. As the course progresses, the homework and even some exam problem will be intentionally or unintentionally ambiguous. Ambiguity is an important aspect of the real world with which you will have to deal. This is another Software Engineering thing. It is critical for you
      1. to recognize ambiguity
      2. to understand the alternatives
      3. to discard obviously silly alternatives
      4. to evaluate your support for (opinion on) the various alternatives
      5. to choose a good one.

    Do not make the mistake that all alternatives (opinions) are equal. That's a rumor. You must learn in your life to analyze and to evaluate the support (argumentation). Then you can make well-informed decisions.

Second, 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 data 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. 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.

Keep in mind that your TA is 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 me.

    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 the Course Instructor if you are unsatisfied with the TA's explanation.