Code Review for Robot Programmers

Review for behavior, safety, and maintainability.

Module 14: Team Workflow and Competition ReadinessTeam

In this lesson, you will:

01Review risky hardware changes.
02Check telemetry and fallbacks.
03Keep comments useful.

Concept narrative

Robot code review is not about style nitpicks first. It is about whether the change can damage hardware, confuse drivers, break autonomous, or make debugging harder.

Robot mental model

A reviewer should ask what behavior changed, how it was tested, what could fail, and how the drive team recovers.

Implementation walkthrough

Use a short checklist for every PR or merge: hardware touched, OpModes touched, tested on blocks, tested on floor, telemetry added, rollback known.

ReviewChecklist.mdJava

- What robot behavior changed?
- Was it tested on blocks?
- Was it tested on the floor?
- Is there telemetry for failure?
- Can we roll back?

Common mistakes and debugging

Reviews fail when they are vague. Saying looks good is not enough for a drivetrain or autonomous change.

Checkpoint

Review asks behavior questions.
Safety is checked.
Testing evidence is included.
The test record includes the setup, prediction, and observed result.
A teammate can repeat the check from the saved evidence without guessing.

Reflection check

Check your understanding before moving on.

Which result best demonstrates completion of “Code Review for Robot Programmers”?

Why record the test setup, prediction, and observed result?

0 of 2 answered

References

Game Manual 0FTC community reference for programming, controls, and robot design.GitHub pull request reviewsOfficial review workflow and review states.