The following are guidelines used by your TAs to grade your assignment 1.
|Code Quality (explained)||(60%)|
|Modularity and Class Organization (10%)||______________|
|Data Abstraction (data forms reflect intent) (15%)||______________|
|No roundabout, confusing approaches (5%)||______________|
|No Repeated Code or Data (magic numbers) (5%)||______________|
|Readability (indentation, variable names, comments) (5%)||______________|
| Appropriate access (
|Appropriate Control Flow constructs, idioms, etc (5%)||______________|
| No unnecessary casting (5%)
|No unjustified gross inefficiencies (5%)||______________|
|Evidence of test code (all classes) (10%)||______________|
|Works on trivial inputs (5%)||______________|
|Works on some inputs (5%)||______________|
|Works on common inputs (5%)||______________|
|Works on all legal inputs (5%)||______________|
| JAR FILE (5%)
Here are some specific explanations of a few items in the guide:
You don't need to describe the purpose of an obvious method (eg
toString() or a constructor), if it is straightforward.
Nor do you need to describe a method in a subclass, if it's been described
in the (perhaps abstract) superclass.
breakif there is a straightforward alternative (there usually is), declare types as
final staticwhen possible, etc.
Unjustified inefficiencies are using algorithms that are big-Oh worse than needed, w/o any gain in ease of code.
null. All others should be given a name. For instance, rather than just using "120", it should be a named constant like
static final int cruiseSpeed = 120; // km per hr
mainfor that class) as soon as you write it. Note that this means
paramStringis one of the first methods you write for a class, so that you can print out debugging versions of your object.
If your function returns an incorrect answer, please note this in your
SomeFile.javaisn't really late i just forgot to copy it with
You can presume that the grader is familiar with the assignment handout. The documentation -- which can also be in the README file -- is intended for another programmer who might be modifying your code. It has an overview of what the main classes of your program are, how they relate and interact, and the main approach taken to solve the problem. Conciseness is desired in all documentation; there is no requirement that documentation necessarily be lengthy. Clear English composition is expected.
Remember that your README should mention what features don't work, if you didn't have time to complete the assignment.
Keep in mind that your graders are grading a large number of programs, 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 a grader or Course Instructor(s) if you are unsatisfied with a grader's explanation.