Your code is only half of what a grader sees. The other half is documentation: the comments inside your files, the README that explains how to run the program, and the notes you attach when you submit. Graders read all three. Most coding rubrics assign points to them directly. A student who writes clean code and skips the documentation loses marks already earned. Here is how comments, README files, and submission notes move your grade, and what graders look for in each.
What Documentation Means in a Coding Assignment
Documentation in a coding assignment is every piece of writing that explains your code without being part of the code’s logic. It takes three forms, and graders treat each one differently.
Code comments are the lines inside your source files that explain what a block does and why. They sit next to the logic they describe.
A README file is a separate document, usually named README.md, that explains how to run the program. It lists dependencies, setup steps, and the layout of your files.
Submission notes are the message you leave for the grader at upload. Some platforms call this a submission comment. The note states what works, what stays unfinished, and any known issue.
Each form covers different ground. Comments explain the code from the inside, while the README handles everything that happens before the code runs. Submission notes report the state of the work on the day you hand it in.
How Much of Your Grade Documentation Controls
Documentation rarely gets its own line on a rubric. It sits inside a larger category, usually style or code quality. That category carries real weight.
At the University of Chicago, the CMSC 12100 rubric splits each assignment into four parts. Those parts are completeness, correctness, design, and style. Style counts for 10 to 20 percent of the grade. Documentation lives inside that style score. The rubric sets a flat rule: every function you write has a docstring. A missing docstring costs style points.
At the University of Washington, CSE 143E grades most assignments out of 20 points. About 11 points cover whether the program behaves correctly. The other 9 points, or 45 percent, cover code quality. Comments and readable structure fall inside that block.
The exact split changes from class to class. The pattern holds across both. Documentation is graded, and the writing around your code accounts for 10 to 45 percent of the marks on a typical assignment. On work that already runs, that range is the difference between a B and an A.
How Code Comments Affect Your Grade
Comments affect your grade through the clarity portion of the style score. A grader reads your comments to confirm you understand your own code. Strong comments raise that score. Weak or absent comments drop it, even when the program runs perfectly.
What Graders Check in Your Comments
A grader checks whether your comments explain the reasoning behind the code, not the syntax itself. The CMSC 12100 style criteria list three clarity checks: descriptive variable names, comments on hard-to-follow logic, and no unexplained magic numbers. Every function carries a docstring that states its purpose, its parameters, and what it returns. Comments earn marks when they sit where a reader pauses, such as an edge case or a non-obvious choice.
Comment Habits That Lose Points
The fastest way to lose comment marks is restating the code in plain English. A line that reads x += 1 gains nothing from a comment that says add one to x. Graders read that as filler.
Three other habits cost real points. Dead code left commented out signals an unfinished cleanup. Comments that contradict the current code show the file changed while the notes stayed behind. Missing docstrings break the one rule most rubrics state outright.
What a Graded README File Needs
A graded README gives the grader everything required to run your program on the first try, on a machine that is not yours. The grader opens your folder, reads the README, and follows it step by step. If the program runs, the README did its job. If it stalls, you lose the marks tied to it.
The Sections Graders Expect
Graders expect four sections: what the program does, how to set it up, how to run it, and how the files are organized. The setup section lists dependencies and the exact install commands. The run section gives the command that starts the program, plus a sample input and expected output where the assignment calls for them.
UNC COMP 523 README assignment shows the standard in practice. It asks for a short summary of the project and a prerequisites section that names every piece of software to install, the specific install commands, and any operating-system assumptions behind them.
README Gaps That Cost Points
The gap that costs the most is a README written for your machine instead of the grader’s. Code that runs on your laptop fails on theirs when a dependency goes unlisted or a version goes unstated. The grader hits an error, the program does not start, and the marks tied to setup disappear.
Three gaps show up again and again. A missing dependency list forces the grader to guess what to install. A run command that skips a step you did from memory breaks the sequence. A file structure left unexplained sends the grader hunting for the entry point.
How Submission Notes Earn Partial Credit
A submission note earns partial credit by showing the grader what works and what does not. The note reaches them before they read a line of your code. It does not change an autograder score, since tests run the same regardless. It changes how a human reviewer reads incomplete work, and that is where partial credit gets decided.
Stanford CS107 grading explains the mechanic behind partial credit. A program that implements some features correctly earns the points for those features, even when other parts stay broken. A note that lists the working parts sends the grader straight to the marks you earned. Without it, a reviewer who hits an early crash assumes the rest fails too.
The University of Rochester CSC 254 makes that note a graded requirement. Students explain the limitations and known bugs in their submission, along with any extra features. The course states the consequence plainly. Leave out a known bug, and the grader assumes you never noticed it. Leave out an extra feature, and you lose the credit for it.
A useful note covers three things: the parts that run correctly, the parts that fail and what you attempted on them, and any assumption you made where the assignment was unclear. The grader then spends less time guessing and more time awarding the points your working code already earned.
Documentation Checklist Before You Submit
Run this list before you upload. Each item maps to marks covered earlier in this post.
- Add a docstring to every function that states its purpose, its parameters, and what it returns.
- Comment the logic a reader pauses on, and skip the lines that explain themselves.
- Remove commented-out dead code, and fix any comment that no longer matches the code.
- Write a README with four parts: what the program does, setup, the run command, and file layout.
- List every dependency with its version.
- Give the exact command that starts the program, with sample input and output where the assignment calls for them.
- Note the parts that run correctly and the parts that fail.
State any assumption you made where the assignment was unclear. - None of these items take long, and each one protects marks already earned by working code.
Frequently Asked Questions
Does documentation affect a coding homework grade?
Yes. It sits inside the style or code-quality score, which carries 10 to 45 percent of the marks depending on the course. A program that runs perfectly still loses those marks when the documentation is missing.
How much commenting does a coding homework assignment require?
Enough to explain the reasoning a reader pauses on, plus a docstring on every function. Comments that restate the code add nothing. Comments on edge cases and non-obvious choices earn the clarity marks.
Do README files get graded?
Yes, when the assignment asks for one. Graders use the README to run your program, so a README that lists dependencies, setup, and the run command protects the marks tied to setup. Some courses, like UNC COMP 523, grade the README as a separate requirement.
What happens to my grade if my code works but has no documentation?
The functionality score holds, since tests run on behavior. The style or code-quality score drops. On many rubrics that gap is a full letter grade, which is why documentation matters as much as a working program.
Good documentation starts with understanding your own code well enough to explain every part of it. That same understanding is what lets you defend a solution in office hours. Students who want a worked example with the explanation built in sometimes search do my coding homework and study the walkthrough that comes with the solution.