Teaching code review checklist in Grades 11-12 (Level 2) unit cover (OAS L2.AP.PD.04)

Teaching Systematic Code Review in Grades 11-12 (Level 2): Oklahoma Standard L2.AP.PD.04

Teaching Systematic Code Review in Grades 11-12 (Level 2): Oklahoma Standard L2.AP.PD.04

Teaching code review checklist in grades 11-12 (level 2) does not have to be complicated. Picture a software engineer reviewing a teammate's pull request against a six-criteria checklist before approving it for the shared codebase. That kind of thinking is exactly what Oklahoma's grades 11-12 (level 2) computer science standard L2.AP.PD.04 asks students to practice — and it is very teachable with the right materials. This post walks through what the standard means, the misconceptions students bring to it, and discussion starters you can use tomorrow, whether you teach in a classroom or at your kitchen table.

What Does Standard L2.AP.PD.04 Actually Ask?

Systematically examine code for correctness, usability, readability, efficiency, portability, and scalability through peer review. — Oklahoma Academic Standards for Computer Science (February 2023)

In plain language: This standard asks students to systematically check code against six specific qualities: does it work correctly (including in unusual situations), is it easy and safe for people to use, is it easy for another programmer to read, does it run efficiently, will it work on a different computer, and will it keep working if it gets much bigger or more popular.

In student-friendly terms, the learning target is: "I can systematically examine a piece of code for correctness, usability, readability, efficiency, portability, and scalability, and I can write specific, constructive feedback for any criterion the code fails."

What Students Should Be Able to Do

  • I can test a piece of code against edge cases, not just typical inputs, to evaluate its correctness.
  • I can distinguish readability, efficiency, portability, and scalability from one another and give an example of each.
  • I can write feedback that names a specific criterion, points to a specific line or behavior, and suggests a concrete fix.
  • I can explain why peer review is a standard, expected practice in professional software development rather than a punishment.

Along the way, students pick up the working vocabulary of the topic: correctness, usability, readability, efficiency, portability, scalability, peerreview, edgecase, readable, modularity, checklist, refactor, documentation, constructive.

Code Review Checklist: Misconceptions to Watch For

These are the wrong turns students reliably take with this standard — knowing them ahead of time is half the lesson plan. Each correction strategy below comes straight from the unit's teacher guide (the paragraph and activity references point into the unit itself).

1. "If code produces the right answer once, it is correct."

Return to paragraph 2's edge-case discussion. Have students deliberately construct an empty list, a zero, or a negative number for a function and trace through what actually happens, showing that one successful test does not prove correctness across all inputs.

2. "Code review is about catching mistakes and criticizing the author."

Return to paragraph 9. Reframe review as a routine, expected quality-assurance step every professional team uses, and model giving feedback that is specific and paired with a suggested fix rather than a judgment of the person.

3. "Efficiency and scalability mean the same thing."

Use the Loops vs. distinction from paragraph 5 and 7 side by side: efficiency is about one algorithm's cost as one input grows, while scalability is about the whole system's performance as overall usage grows. Have students give a real-world example of each separately.

4. "As long as code works on my computer, it's ready to share."

Connect to paragraph 6's portability discussion. Point out that 'it works on my machine' is exactly the sentence that precedes real production failures, and have students find the hidden assumption (a file path, a setting) in a short example that would break elsewhere.

Discussion Starters You Can Use Tomorrow

  • Why might a piece of code pass every automated test a computer can run and still fail a human peer review?
  • Of the six criteria, which do you think matters most for a program used by millions of people, and why?
  • Describe a time outside of computer science where 'systematic' checking (a pilot's pre-flight checklist, a nurse's medication check) prevented a mistake a quick glance would have missed.

Bringing It Home

This topic is a natural one for families. One ten-minute activity to try: Together, pick a set of written instructions around the house (a recipe, a chore checklist, directions to a relative's house) and have your student 'review' it: is each step correct, is it easy for a stranger to follow, and would it still work if the situation changed (double the guests, a different kitchen)? There are no wrong answers — the goal is hearing their reasoning about what makes instructions genuinely reliable.

Where This Leads

Students who can systematically examine a piece of code for correctness, usability, readability, efficiency, portability, and scalability, and write specific, constructive feedback for any criterion the code fails are building skills used every day in software engineering, site reliability / DevOps engineering, security engineering, engineering management, and computer science education.

See the Unit in Action

Get the Complete L2.AP.PD.04 Unit

I built a complete, no-prep unit for this standard — Systematic Code Review: Examining Correctness, Efficiency, and Scalability — covering 3-4 days of instruction across 43 pages:

  • Teacher guide — day-by-day pacing, misconceptions to watch for, discussion questions, differentiation for support / ELL / extension, and a 4-point rubric
  • Student learning target page — a kid-friendly "I can" statement with success criteria
  • Full content lesson with 3 embedded "Check Your Understanding" checkpoints
  • 12-question assessment (6 multiple choice, 4 true/false, 2 short answer) with a complete answer key, explanations, and exemplar responses
  • Group activity — "Six-Criteria Code Clinic" (25-30 minutes)
  • Individual activity — "My Code Review Log" (20-25 minutes)
  • Crossword and word search built from all 14 vocabulary terms (with answer keys)
  • Family connection letter — a plain-language page for parents, with dinner-table questions and a 10-minute home activity
  • Certificate of achievement — ready to sign and send home
  • Code Review Card Set: Six Criteria in Practice (separate printable, 2 pages)
  • Reference Notes: The Six Review Criteria (separate printable, 1 page)
  • My Code Review Log (separate printable, 2 pages)

Get Systematic Code Review on Teachers Pay Teachers →

Also aligned to CSTA 3B-AP-21: Systematically test and refine computational artifacts, taking into account a variety of factors, such as correctness, usability, readability, and accessibility.

Every Sooner Standards resource is built directly from the official Oklahoma Academic Standards for Computer Science (February 2023) — standard text verified, never paraphrased from memory.

Similar Posts

Leave a Reply