Marking scheme for Racket assignments
This scheme is subject to adjustment as the term progresses. I’ll try to let you know, but you’re responsible for checking it before you do each assignment.
Assignments that generate errors (e.g. syntax errors, type errors, or exceptions) when run will not be accepted by the handin-server. You can always comment out broken code.
It’s possible (for undergrads) to get bonus marks on (parts of) the assignments, but don’t expect it to be easy.
I’ll select 5 tests from the assignment as submission tests. You’ll be notified at submission time if your code is failing any of these tests. Each such failure will be penalized by 10%, and several annoying button clicks.
If you don’t have complete test coverage, your total mark will be multiplied by 0.8.
The remaining 50% of the marks will be assessed according to the following breakdown.
The columns are for calibration, it’s possible to get marks in between.
numbers in angle brackets are deductions (or bonus) on the handin server.
| Undergrads | Excellent (105%) | Good (75%) | Minimally satisfactory (55%) | Needs improvement (0%) |
| Graduate Students | 100% | 70% | 50% | 0% |
| Correctness (20) 1 | Correct to the spirit of the assignment. Shows evidence of deeper understanding of the assignment, or defensive programming. <+1> / <+0> |
Correct to the letter of the assignment. No obvious bugs. <-5> / <-6> |
Almost completely correct, perhaps one incorrect case / input. <-9> / <-10> |
Some serious correctness problem. <-20> |
| Test Design (10) 2 | At least one extra test per function, tests are designed and documented with respect to problem definition. Corner cases are considered. <+0.5> / <+0> |
At least one extra test per function. <-2.5> / <-3> |
Complete test coverage, as indicated by DrRacket <-4.5> / <-5> |
Incomplete test coverage, as indicated by DrRacket <-10> |
| Coding Style (10) 34 | Meaningful identifiers. Good racket indentation Good line width and line breaks. Granularity of functions is well thought out. <+0.5> / <+0> |
Meaningful identifiers. Good racket indentation. Good paren placement. <-2.5> / <-3> |
Meaningful identifiers. Reasonable indentation. <-4.5> / <-5> |
Pervasive bad identifiers or bad indentation. <-10> |
| Idiom (10) 5 6 | No inappropriate mutation or global variables. Follows assignment specified constructs and / or library functions. Solution is elegant. <+0.5> / <+0> | No inappropriate mutation or global variables. Follows assignment specified constructs and / or library functions. <-2.5> / <-3> |
No inappropriate mutation or global variables <-4.5> / <-5> |
Inappropriate mutation or global variables. <-10> |
For top marks here, I’m expecting you to deal correctly with some aspect of the problem not completely specified in the assignment.↩︎
Note that you are penalized twice for missing test coverage. Don’t do that.↩︎
For basic style issues, see the Official Racket Style guide↩︎
By granularity I mean the organization of code using local bindings and functions to avoid code duplication and make it easier to read.↩︎
Elegance of code is pretty subjective. Conciseness is part of it, but only because it often makes the entire solution easier to comprehend. To get top marks here the TA or prof should wish they had come up with your solution.↩︎
Unless the assignment specifically calls for it, or you clear it with the prof beforehand, mutation and global variables are inappropriate.↩︎