Computer Science
Grade 9
20 min
Code Reviews
Code Reviews
Tutorial Preview
1
Introduction & Learning Objectives
Learning Objectives
Define the purpose and importance of code reviews in a software project.
Identify the key roles in a code review process, such as Author and Reviewer.
Formulate constructive, specific, and kind feedback on a piece of code.
Differentiate between a logic error, a style issue, and a personal preference.
Apply best practices for both giving and receiving code review feedback.
Use the comments feature in a platform like GitHub or Replit to conduct a basic code review.
Ever had a friend find a typo in your essay right before you handed it in? 📝 Code reviews are the computer science version of that, helping us catch bugs and improve our work together!
In this lesson, you'll learn how to review code written by others and how to handle feedback on your own...
2
Key Concepts & Vocabulary
TermDefinitionExample
Code ReviewThe process where developers other than the original author of a piece of code examine it for mistakes, improvements, and quality.Before adding a new 'jump' feature to a game, a teammate looks over the jump code to make sure it works correctly and doesn't break anything else.
AuthorThe person who wrote the code that is being reviewed.You just finished writing a function to calculate a student's average grade. You are the Author.
ReviewerThe person (or people) who reads and provides feedback on the Author's code.Your project partner reads your grade-calculating function to check your math. They are the Reviewer.
Pull Request (PR) / Merge Request (MR)A request to merge new or changed code from one branch into the main project branch....
3
Core Syntax & Patterns
The Constructive Feedback Rule
Comment on the code, not the person. Be kind, specific, and explain your reasoning.
The goal is to improve the code, not to criticize the author. Instead of saying 'This is bad,' say 'This approach might cause a bug if the input is negative. We could add a check to prevent that.'
The Small Chunks Rule
Review small, focused pieces of code (e.g., under 200 lines).
It's very difficult to properly review thousands of lines of code at once. Authors should break their work into small, logical pull requests (like 'Add login button' instead of 'Build entire user system').
The 'Why' Rule
As the author, explain *why* you made your changes in the pull request description.
This gives the review...
4 more steps in this tutorial
Sign up free to access the complete tutorial with worked examples and practice.
Sign Up Free to ContinueSample Practice Questions
Challenging
A junior developer receives a 'Change Request' with the comment: 'This logic is too complex. Could we extract this into a helper function to improve readability?' The developer feels their code is clever and efficient. Synthesizing the tutorial's lessons, what is the best course of action?
A.Explain to the reviewer that they are wrong and the code is actually very clever.
B.Try to understand the reviewer's perspective. Even if the code is clever, if it's hard for a teammate to read, it might be a long-term problem. Consider refactoring as suggested.
C.Ask another developer to approve the code so they can ignore the first reviewer's feedback.
D.Delete the pull request and resubmit it later, hoping a different person reviews it.
Challenging
In a code review, you receive three comments on your pull request. Which one should you prioritize addressing first, and why?
A.suggestion to rename a variable, because it's the easiest to fix.
B.question about your algorithm choice, because it shows the reviewer is confused.
C.comment identifying a bug that crashes the program, because it affects the correctness of the code.
D.All comments have equal priority and should be addressed in the order they appear on the screen.
Challenging
You are asked to review a pull request that is 1,000 lines long and touches 15 different files. You can see it has several issues. According to the tutorial's principles, what is the most constructive first step for you as the reviewer?
A.Leave a single comment asking the author to split the pull request into several smaller, more focused ones.
B.Spend the next three hours meticulously commenting on every single issue you can find in all 1,000 lines.
C.Reject the pull request without a comment because the author should have known better.
D.Approve the pull request because it's too much work to review properly.
Want to practice and check your answers?
Sign up to access all questions with instant feedback, explanations, and progress tracking.
Start Practicing Free