Rubric for Programming Assignments¶
Programming assignments will be graded according to the following general rubric. The exact weights will vary from one assignment to another, but will be specified in each individual assignment.
Completeness (50-70% of grade): This score will be determined by the result of running a series of automated tests on your code. The tests check whether your code implements the tasks we ask you to implement in the assignment and, thus, are a good measure of how complete your code is. You will be able to run these tests yourself, and thus know what your Completeness score is before you submit your assignment.
Correctness (10-30% of grade): This score encompasses issues with your code that, while not explicitly captured by the tests, could lead to incorrect behaviour (or simply neglect to implement something we told you to implement).
We will usually provide you some hints on what we will be looking out for in this component of the rubric. Please note that this section of the rubric will never re-penalize you for a failure that is already captured by the tests. So, if your code fails to implement something we told you to implement, but that is already captured by the tests, we would not re-penalize you here.
Design (0-20% of grade): This score will be determined by “qualities, many of which are intangible, that don’t have to do with (and exist to some extent independently of) the correct operation of your code.” (thanks to Adam Shaw for this concise phrasing). For example, in many assignments you will have to decompose your code into multiple functions, where that decomposition is up to you. Whether your decomposition makes sense and is well designed would be evaluated in this score.
Style (10-20% of grade): This score will be determined by your adherence to our Style Guide. We will generally be looking at the following:
Documenting functions: Every function written by you must have a docstring.
Clarity: Your code must be easy to read and understand. This is a fairly subjective aspect, but common deductions for lack of clarity include using variables without descriptive names, writing convoluted code that would be easier to understand with more code comments, using magic numbers, etc.
General adherence to the style guide: The graders will not be checking that you follow every minute aspect of our style guide, and occasional infractions are ok (and won’t necessarily be penalized). For example, if you had one or two lines with more than 80 characters, we would likely not penalize you for that. If your code was riddled with lines longer than 80 characters, we would definitely take points off. In general, we’re looking for your code to use consistent style, and one which asymptotically approaches the one specified in our style guide.
Please note that submitting broken code (i.e., code with syntax errors or, in general, code that we cannot run) will result in point penalties. In the first programming assignment, submitting broken code will result only in a warning but, starting with the second programming assignment, broken code will receive an automatic 10 point penalty (out of 100 possible points).
Please note that if your code is so broken that we cannot get it to work with a few simple fixes, it will simply not get graded at all and you will receive a zero on the assignment.
Fortunately, it is very easy to avoid submitting broken code! Gradescope will run the automated tests whenever you make a submission, and this can let you know if there are any major issues with your code (e.g., if you made a silly syntax error right before submitting, causing all your tests to fail). It is always a good idea to make a “test submission” on Gradescope to ensure that your code runs correctly. Remember: you can make as many submissions as you want on Gradescope before the deadline. We will only look at your latest submission.