Computer Science Grade 8 20 min

Code Reviews

Code Reviews

Tutorial Preview

1

Introduction & Learning Objectives

Learning Objectives Differentiate between stylistic, logical, and security-related feedback in a code review. Formulate constructive, specific, and actionable comments on a piece of code. Identify at least three common 'code smells' such as magic numbers, long methods, and non-descriptive names. Explain the purpose of a style guide and apply its rules during a review. Analyze a code change to ensure it is efficient and maintainable. Use the 'praise-suggest-praise' sandwich method for delivering feedback kindly. Ever built something with LEGOs and had a friend suggest a better way to make it stronger? That's what a code review is for your programs! 🧐 In this lesson, we'll move beyond just finding typos and bugs. We'll learn the advanced ar...
2

Key Concepts & Vocabulary

TermDefinitionExample Code SmellA 'code smell' is not a bug, but a hint in the code that suggests a deeper problem. It's a sign that the code could be simplified or designed better.A very long function that does ten different things is a code smell. It suggests the function should be broken down into smaller, more focused functions. RefactoringThe process of restructuring existing computer code—changing the internal structure—without changing its external behavior. The goal is to improve the code's design, making it easier to read and cheaper to maintain.Renaming a variable from `x` to `player_score` is a simple refactor. It doesn't change what the program does, but it makes the code much easier to understand. Style GuideA set of rules for how to write and format...
3

Core Syntax & Patterns

The 'Why', Not Just the 'What' When suggesting a change, explain *why* it's better. Link to a style guide, explain the performance benefit, or describe how it improves readability. Use this rule to make your feedback educational, not just critical. It helps the author learn and prevents arguments by providing objective reasons for your suggestions. Be Specific and Actionable Avoid vague comments. Instead of 'This is confusing,' write 'This variable name `data` is not descriptive. Could we refactor it to `user_profile_list` to clarify what it contains?' Apply this rule to every comment you write. The author should know exactly what you are referring to and have a clear idea of how to address your feedback. Automate the Small St...

4 more steps in this tutorial

Sign up free to access the complete tutorial with worked examples and practice.

Sign Up Free to Continue

Sample Practice Questions

Challenging
A teammate submits a Pull Request for a new feature. The code works perfectly and has no bugs. However, it uses variable names like `a`, `b`, `c`, contains a 200-line long function, and ignores all team formatting rules. What is the best overall feedback strategy?
A.Approve the PR immediately because it works correctly.
B.Request changes, focusing on improving maintainability by fixing the code smells like poor names and the long function.
C.Reject the PR and tell the teammate to start over from scratch.
D.Approve the PR but fix all the names and formatting yourself in a future change.
Challenging
An automated linter flags 30 minor style issues in a PR. While reading the code, you discover a serious security flaw where a user could delete another user's data. What is the most critical and responsible action for you as the reviewer?
A.Leave 31 comments: one for each style issue and one for the security flaw.
B.Comment only on the style issues, since the linter found them.
C.Ignore all the issues and approve the PR to be nice.
D.Leave a single, high-priority comment explaining the security flaw and request immediate changes, treating the style issues as secondary.
Challenging
You are reviewing a function that uses a very clever but complex algorithm. It is highly efficient but so difficult to understand that no one else on the team can figure out how it works. What is the best course of action, considering the principle of maintainability?
A.Approve it immediately because efficiency is the most important factor.
B.Reject it because clever code is always bad.
C.Ask the author to add detailed comments explaining the algorithm, and consider if a simpler, slightly less efficient but more readable solution exists.
D.Rewrite the code yourself using a simpler method and push it to their branch.

Want to practice and check your answers?

Sign up to access all questions with instant feedback, explanations, and progress tracking.

Start Practicing Free

More from Advanced Topics

Ready to find your learning gaps?

Take a free diagnostic test and get a personalized learning plan in minutes.