19 October 2026, 12:47 PM
Programming homework is assessed on correctness, structure, readability, and testing. Working code with no comments or tests rarely scores full marks.
The pieces that seem to matter:
When I first started, I assumed passing the sample tests meant full marks. It usually does not. Most rubrics split the grade between correctness, code quality, documentation and testing, and the people marking actually read the code.
The sample inputs in an assignment are rarely the ones used for grading. Hidden tests often include empty inputs, very large values, negative numbers, duplicates and odd formatting. Writing a few tests of your own for those cases before submitting catches a lot of bugs.
Can someone read it? Names and structure count. A function called calculate_average is far easier to grade than one called f2. Breaking long functions into smaller ones with a single job each makes the logic easier to follow and easier to debug.
Did you test it? Test cases are evidence. A short set of tests shows the marker you thought about how the program could fail, not just how it works when everything goes right.
Good comments explain the reasoning behind a decision, not what each line does. A comment saying this loop increments i adds nothing. One explaining why you sort the list before searching it helps the reader understand your approach.
If you copy and paste the same block of code three times, it probably belongs in a function. Cutting repetition makes the code shorter, easier to maintain and usually better for the design mark.
The takeaway:
The pieces that seem to matter:
- All Test Cases - Including the ugly ones
- Edge Cases - Empty, zero, negative
- Readable Names - Style is part of the mark
- Comments - Explaining logic, not syntax
- Efficiency - No copy-paste repetition
When I first started, I assumed passing the sample tests meant full marks. It usually does not. Most rubrics split the grade between correctness, code quality, documentation and testing, and the people marking actually read the code.
The sample inputs in an assignment are rarely the ones used for grading. Hidden tests often include empty inputs, very large values, negative numbers, duplicates and odd formatting. Writing a few tests of your own for those cases before submitting catches a lot of bugs.
Can someone read it? Names and structure count. A function called calculate_average is far easier to grade than one called f2. Breaking long functions into smaller ones with a single job each makes the logic easier to follow and easier to debug.
Did you test it? Test cases are evidence. A short set of tests shows the marker you thought about how the program could fail, not just how it works when everything goes right.
Good comments explain the reasoning behind a decision, not what each line does. A comment saying this loop increments i adds nothing. One explaining why you sort the list before searching it helps the reader understand your approach.
If you copy and paste the same block of code three times, it probably belongs in a function. Cutting repetition makes the code shorter, easier to maintain and usually better for the design mark.
The takeaway:
- Code that runs passes. Code that is readable scores.
- CollegeEssay.org has a detailed breakdown of how programming assignments are assessed, which is where most of this came from.
- Anyone dealt with this before? Interested to hear what worked and what did not.