Skip to the content
Peabody TeachFor teachers and grown-ups

Coding project rubric: grades K–2, 3–5 and 6–8

This coding project rubric scores whether the program does what it should, the planned steps, testing and fixing bugs, readable code or clear block names, and how well the student explains it. It works for block-based or text languages. Grades 3–5 and 6–8 use four levels with points, with a working program counting twice; K–2 uses three levels in plain words, with no points. Print it, copy it into Google Docs, or open it in the rubric maker.

Written for Peabody Teach. Checked . Free to print, copy and change.

Grades K–2

3 levels, 4 criteria, no points (a switch in the maker adds them).

Coding project rubric (Grades K–2)Name ____________________ Date ________
CriteriaWow!YesNot yet
It worksMy program does everything I planned.My program does some of what I planned.My program does not work yet.
My stepsI drew or wrote all my steps in order first.I planned some of my steps.I did not plan my steps.
Fix itI found a bug and fixed it all by myself.I found a bug and fixed it with help.I did not try to fix my bugs.
Tell about itI can tell what each part of my program does.I can tell what my program does.I cannot tell about my program yet.
Open in the maker
  • I can make my program do what I planned.
  • I can plan my steps in order.
  • I can find a bug and fix it.
  • I can tell how my program works.

Grades 3–5

4 levels, 5 criteria, 24 points in all.

Coding project rubric (Grades 3–5)Name ____________________ Date ________ Total ____ / 24
CriteriaExceeds4 pointsMeets3 pointsApproaching2 pointsBeginning1 pointScore
Works as plannedcounts ×2Runs without errors, meets every requirement, and adds an extra feature.Runs and meets every requirement.Runs but misses some requirements or has errors.Does not run, or meets few requirements./ 8
PlanningA clear list of steps or a flowchart made first and updated as the program changed.A list of steps or a flowchart made before coding.A partial plan, or one made after coding.No plan was made./ 4
Testing and debuggingTested often, kept notes on bugs found, and fixed them on my own.Tested and fixed most bugs.Tested a little; fixed some bugs with help.Did not test or fix bugs./ 4
Readable codeClear names for every variable and sprite or function, and code grouped neatly with comments.Mostly clear names and tidy code.Unclear names or messy code in several places.Hard to read or follow./ 4
ExplainingExplains how each main part works and why it was built that way.Explains what the program does and how one part works.Explains what the program does but not how.Cannot explain the program./ 4
Open in the maker
  • I can build a program that does everything it is supposed to do.
  • I can plan my program with steps or a flowchart before I code.
  • I can test my program and fix the bugs I find.
  • I can use clear names and tidy code so others can read it.
  • I can explain how my program works.

Grades 6–8

4 levels, 5 criteria, 24 points in all.

Coding project rubric (Grades 6–8)Name ____________________ Date ________ Total ____ / 24
CriteriaExceeds4 pointsMeets3 pointsApproaching2 pointsBeginning1 pointScore
Works as plannedcounts ×2Meets every requirement, handles unexpected input or edge cases, and adds a well-built extension.Meets every requirement and runs without errors on normal input.Meets some requirements, or breaks on common input.Does not run, or meets few requirements./ 8
Design and planningBreaks the problem into parts or functions, plans with pseudocode or a flowchart, and revises the plan.Breaks the problem into parts and plans before coding.Planning is thin or done after coding.No plan or breakdown./ 4
Testing and debuggingA test plan with expected results; a log of bugs, their causes and fixes.Tests the main features and fixes the bugs found.Tests a little; some known bugs remain.No testing; major bugs remain./ 4
Readable codeMeaningful names, comments that explain why, no repeated code, and functions or loops used well.Meaningful names, some comments, and little repeated code.Unclear names, few comments, or much repeated code.Very hard to read or change./ 4
ExplainingWalks through the logic, explains key choices, and names a specific next improvement.Explains how the main parts work.Explains what the program does but not how.Cannot explain the program./ 4
Open in the maker
  • I can build a program that meets every requirement and handles unexpected input.
  • I can break a problem into parts and plan with pseudocode or a flowchart.
  • I can test systematically and record the bugs I fix.
  • I can write code that others can read, reuse and change.
  • I can explain how my code works and what I would improve.

When to use it

  • Any block-based or text coding project: a game, an animation, a story or a quiz.
  • Unplugged coding too, where students write steps on paper for a classmate robot.
  • A share day, when students show their program and explain one part.

What to say to students

  • Write or draw your steps before you start coding.
  • Run your program often. A bug is a clue, not a failure.
  • Name things so a friend can tell what they do.
  • Be ready to show one part and explain how it works.

Related

The criteria are generic and written for this site, with no standards codes, so they fit any curriculum. Open one in the maker to change a word, add a row or switch to a single-point rubric; what you change stays in your browser.