Rubric for Programming Assignments

As explained on our Grading page, you will receive two ESNU scores on each programming assignment: one for completeness and one for code quality.

Your completeness score is 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.

Your code quality will be determined on the basis of three aspects of your code:

• Correctness: This encompasses issues with your code that, while not explicitly captured by the tests, could lead to incorrect or inefficient behaviour in your code. This can include small mistakes in your code, as well as larger issues that reveal a lack of mastery in the material.

• Design: This encompasses “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). In several programming assignments, this will relate to how you choose to decompose a complex problem into multiple functions, or into a series of classes (in the object-oriented sense of the word).

• Style: This encompasses your adherence to our Style Guide.

ESNU criteria for code quality

In general, your code quality score will follow the criteria described below. Each programming assignment will specify additional requirements, including examples of what will be considered minor and major correctness issues in that programming assignment. Design criteria are very assignment-specific, and they will be described in the assignments where design is a key aspect of your code quality.

However, please remember that it is not possible for us to give you an exhaustive list of every single thing that could affect your code quality score (and that thinking in those terms is generally counterproductive to learning how to program; see our How to Learn in this Class page for more details).

• Exemplary:

  • At most a few small mistakes in the code that would only require minor changes to be fixed, and that don’t reveal a lack of mastery in the material, or a fundamental misunderstanding of programming concepts.

  • The code generally adheres to the style guide, including, but not limited, to:

    • All or nearly all the functions written by the student have a docstring that follows the format shown in the style guide.

    • All or nearly all the functions written by the student have a descriptive name

    • No more than three lines exceeding 80 characters.

    • Proper indentation is followed throughout most of the code.

    • Code comments are included in complex pieces of code that may not be self-explanatory

• Satisfactory:

  • The code is overall correct, but includes a few places where the student misunderstood a programming concept at a fundamental level, and addressing this mistake would require reviewing those concepts first.

  • The code adheres to the style guide for the most part, allowing for some of the following:

    • Most of the functions written by the student include a descriptive docstring, although it may not follow the format in the style guide.

    • Between 3 and 10 lines exceeding 80 characters

    • Improper indentation used only infrequently.

    • Only a few variables or function names with unclear names.

• Needs Improvement

  • The code exhibits one or more of the following:

    • Multiple locations throughout the code where the student misunderstood programming concepts at a fundamental level.

    • Pervasive lack of adherence to multiple parts of the style guide.

    • Multiple instances of convoluted code that would need major rewrites to be at a satisfactory level.

• Ungradable

  • The code exhibits one or more of the following:

    • The student did not submit any code

    • None of the tasks include any actual Python code, and instead include pseudocode or code comments describing the general approach to a solution.

    • The student attempted to pass the tests by rote (i.e., wrote code that checked only for the inputs tested by the tests, and returned the expected output, instead of writing a general solution)

Broken code

Please note that submitting broken code (i.e., code with syntax errors or, in general, code that we cannot run) will result in a Needs Improvement in your code quality score, but only as long as getting your code to run involves a few simple fixes. If your code is so broken that we cannot get it to work with a few simple fixes, it will receive an Ungradable.

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.