How do I grade a program that works but the student clearly didn't write themselves?

Lean hard on 'Documentation & ability to explain the code.' A student who can't walk through their own submission and explain what a section does — even if it runs correctly — should score at the bottom of that row regardless of how well the program performs elsewhere. Ask a live follow-up question about one specific line during grading if you suspect this.

Should style (naming, formatting) matter as much as whether the code works?

Not usually — 'Functionality & correctness' and 'Code organization & readability' are separate rows for exactly this reason. A student can write a program that works but is disorganized (high on functionality, low on readability), or a beautifully organized program with a bug (the reverse). Weight functionality more heavily if you want working code to matter most.

What language or platform does this rubric assume?

None — the five rows (functionality, readability, problem-solving, testing, documentation) apply the same way whether the assignment is in Python, Java, Scratch, or a web framework. Only the wording inside a cell may need a small adjustment for a block-based language like Scratch, where 'variable names' and 'functions' map to blocks and custom blocks.

How much should I weight testing for a short, low-stakes assignment?

Reduce it, not drop it — even a small assignment benefits from checking one edge case beyond the obvious example, and that habit is worth reinforcing early. For a very short exercise, lower the top-level bar on 'Testing & handling edge cases' to require just one edge case check rather than several.

Coding Project Rubric Template

A ready-to-use, analytic coding project rubric for Programming project (app, game, script, or website) in any language (Grades 6–12 and college). Score whether the code actually works, is organized well enough for someone else to read, and reflects the student's own problem-solving — not just whether the final output looks impressive. Edit it for your own assignment, print it, or copy it into Google Docs.

Edit this template in the maker →

The coding project rubric

Criterion	Excellent (4)	Proficient (3)	Developing (2)	Beginning (1)
Functionality & correctness	The program runs without crashing and correctly performs every feature described in the assignment, including how it responds to invalid or unexpected input.	The program runs and performs all core features correctly; one minor feature is missing or behaves incorrectly in an edge case.	The program runs but has at least one feature that doesn't work as intended, or it crashes under some inputs a user would reasonably try.	The program does not run, or it runs but fails to perform the assignment's core features.
Code organization & readability	Uses clear, descriptive variable and function names, consistent indentation, and breaks the program into logical functions or sections instead of one long block.	Names and structure are mostly clear; one section is a long unbroken block or has a few unclear variable names (e.g. x, temp, data2).	Structure is inconsistent — indentation varies, several variable names are unclear, or the program is not broken into functions where it reasonably should be.	Code has no consistent structure, naming, or indentation; it would be very difficult for another person to follow.
Problem-solving & algorithm design	Chooses a logical, appropriately efficient approach to the problem and can explain why that approach was chosen over an alternative.	Chooses a working approach to the problem; it is not the most efficient option but is reasonable for the assignment's scope.	The approach works for the simplest case but breaks down or becomes needlessly complicated for a slightly harder version of the problem.	No coherent approach is visible — the code appears to be trial-and-error changes until something happened to work.
Testing & handling edge cases	Tests the program against multiple inputs, including at least one edge case (empty input, a boundary value, or invalid input) and fixes issues found.	Tests the program against the expected, typical inputs; edge cases are not explicitly tested, though the program may still handle some correctly.	Testing is minimal — the program was run once or twice with the exact example from the assignment and not checked against anything else.	No evidence of testing; the student cannot describe what inputs were tried before submitting.
Documentation & ability to explain the code	Includes comments or a short write-up explaining what the program does and how, and can walk through any part of the code and explain its purpose when asked.	Includes some comments or a brief write-up; can explain most of the code but is unsure about one section's purpose.	Little to no documentation; the student can explain the program's overall goal but not how specific parts of the code achieve it.	No documentation, and the student cannot explain what a significant portion of the submitted code does.

Four levels — Excellent (4) to Beginning (1). Print this page, or open it in the editor to change the wording, levels, or points.

How to use this rubric

Grading student code often collapses into a binary: did it run, yes or no. That misses most of what actually separates a strong program from a lucky one — whether the logic behind it makes sense, whether another person could read it, whether the student tested it against more than the one example from class, and whether they can explain what their own code does. This rubric grades those as separate rows, so a program that works by trial and error scores differently from one built on a clear, explainable approach, even if both produce the same output on the demo input.

Why these criteria

Each row targets something the assignment is really teaching, with descriptors written to be observable rather than vague:

Functionality & correctness: The most direct test of whether the project succeeds — a program that doesn't run or doesn't do what it claims fails at its one job regardless of how clean the code looks underneath.
Code organization & readability: Grades whether another person — a teacher, a teammate, or the student in six months — could actually read and modify the code, not just whether it happens to work.
Problem-solving & algorithm design: Separates a student who understood the problem and chose a reasonable approach from one who copied a pattern that happens to produce the right output.
Testing & handling edge cases: Rewards a student who checked their own work against inputs that could break it, instead of testing only the one example given in class.
Documentation & ability to explain the code: A working program that the student cannot explain suggests it was copied or pieced together without understanding — this row checks that the student actually knows what their own code does.

How to adapt it

For a first coding assignment with no prior programming class, drop 'Problem-solving & algorithm design' and grade the remaining four rows — efficiency isn't a fair ask before students have written more than a few programs.
For a group coding project, add a sixth row on individual contribution (which parts each student wrote), scored the same way as the Group Project Rubric's 'Contribution & participation' row.
For a web development project instead of a standalone program, fold cross-browser or cross-device behavior into 'Functionality & correctness,' and require in 'Testing & handling edge cases' that the student checked more than one screen size.

Frequently asked questions

How do I grade a program that works but the student clearly didn't write themselves?: Lean hard on 'Documentation & ability to explain the code.' A student who can't walk through their own submission and explain what a section does — even if it runs correctly — should score at the bottom of that row regardless of how well the program performs elsewhere. Ask a live follow-up question about one specific line during grading if you suspect this.
Should style (naming, formatting) matter as much as whether the code works?: Not usually — 'Functionality & correctness' and 'Code organization & readability' are separate rows for exactly this reason. A student can write a program that works but is disorganized (high on functionality, low on readability), or a beautifully organized program with a bug (the reverse). Weight functionality more heavily if you want working code to matter most.
What language or platform does this rubric assume?: None — the five rows (functionality, readability, problem-solving, testing, documentation) apply the same way whether the assignment is in Python, Java, Scratch, or a web framework. Only the wording inside a cell may need a small adjustment for a block-based language like Scratch, where 'variable names' and 'functions' map to blocks and custom blocks.
How much should I weight testing for a short, low-stakes assignment?: Reduce it, not drop it — even a small assignment benefits from checking one edge case beyond the obvious example, and that habit is worth reinforcing early. For a very short exercise, lower the top-level bar on 'Testing & handling edge cases' to require just one edge case check rather than several.