5 exercises — the vocabulary every developer needs to give and receive code reviews professionally in English: approval phrases, design principles, code structure terms, and review etiquette.
A reviewer writes in a pull request comment: "LGTM — minor nit on the variable naming but nothing blocking. Ship it." What does LGTM mean, and what is a nit?
LGTM = "Looks Good To Me" — the most common informal code review approval phrase. It signals the reviewer is satisfied and the change can be merged. It originated in Google's engineering culture and spread across the industry. A nit (short for "nitpick") is a very minor comment — often style, naming, or formatting — that the reviewer explicitly labels as non-blocking. The label matters: without "nit:", the author doesn't know if the comment must be addressed before merging. Code review comment vocabulary: Blocking comment — must be addressed before merge. Non-blocking / nit — optional improvement. Question — reviewer is asking for clarification, not requesting a change. Suggestion — reviewer proposes an alternative. FYI / for context — informational, no action required. TODO — record it for future work, don't fix now. Best practice: label every comment with its intent. An unlabelled comment creates ambiguity and leads to unnecessary back-and-forth.
2 / 10
A senior engineer comments on a PR: "This logic is duplicated in three places — could you extract it into a shared utility function? If not now, please add a TODO with a ticket reference." What principle is the reviewer applying?
DRY (Don't Repeat Yourself) is a software design principle from "The Pragmatic Programmer" (Hunt & Thomas, 1999): "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." When logic is duplicated, a bug fix or requirement change must be applied in multiple places — one missed location introduces inconsistency. Related principles often cited in code reviews: SOLID (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion). KISS — Keep It Simple; don't over-engineer a solution. YAGNI — don't add functionality before it's actually needed. Separation of Concerns (SoC) — different responsibilities should live in different modules. Law of Demeter — objects should only call methods on their direct collaborators. Code review culture note: when asking for a refactor that would delay the PR, it's good practice to offer the TODO alternative — it acknowledges the improvement is real while allowing the current work to ship.
3 / 10
A reviewer leaves this comment: "This is harder to follow than it needs to be — there are three levels of nesting here. Consider early returns (guard clauses) to flatten the structure." What does early return / guard clause mean?
A guard clause (also called an early return) is a pattern where you check preconditions at the top of a function and return (or throw) immediately if they're not met — so the main logic of the function runs "flat" without deep if-else nesting. Without guard clauses:
if (user) {
if (user.isActive) {
if (user.hasPermission) {
// actual logic buried 3 levels deep
}
}
}
With guard clauses:
if (!user) return;
if (!user.isActive) return;
if (!user.hasPermission) return;
// actual logic at top level
Benefits: easier to read (main path is clear), easier to test (edge cases are explicit), lower cyclomatic complexity. Related code review terms: Cyclomatic complexity — a measure of the number of independent paths through a function; high complexity = harder to test. Cognitive complexity — how hard is it for a human to understand the flow (not just count branches). Happy path — the main successful execution path. Edge case — input or condition that deviates from the typical scenario.
4 / 10
In a team code review discussion, someone says: "We should treat this as a drive-by comment — the existing code was already like this before this PR. We don't want to block the author for pre-existing issues." What is a drive-by comment in code review context?
A drive-by comment is a code review comment about an issue that exists in the codebase but was not introduced by the current PR. The author is not responsible for the pre-existing code, and blocking their PR for someone else's old issue is unfair and slows delivery. Best practices: Don't block the current PR for drive-by issues. If the issue is significant, either: open a separate issue/ticket and reference it, or note it as a non-blocking suggestion. The Boy Scout Rule (leave the code better than you found it) is often used to justify fixing drive-by issues — but it's a suggestion, not a requirement to block PRs. Related review etiquette vocabulary: Bike-shedding (Parkinson's Law of Triviality) — spending disproportionate time discussing minor, trivial details (e.g., variable naming) while ignoring significant issues. Rubber stamping — approving a PR without genuine review. Reviewer fatigue — reduced attention quality when reviewing too many large PRs. PR size — smaller PRs get better reviews; large PRs get rubber-stamped.
5 / 10
A reviewer comments: "Could you add a unit test to cover the error path here? The happy path is tested but there's no coverage for when the third-party API returns a 503." What is the error path / sad path, and what contrast does the reviewer make?
In testing and code review, the happy path is the primary, successful execution flow — the scenario where everything works as expected. The sad path (or error path, unhappy path) is the execution flow when something goes wrong: an external service fails, the input is invalid, the database is unavailable, etc. Testing vocabulary: Unit test — tests a single function or unit in isolation, with dependencies mocked. Integration test — tests how components interact (e.g., service + database). Test coverage — the percentage of code lines, branches, or paths covered by tests. Edge case — a boundary condition or unusual input that may expose bugs. Test-Driven Development (TDD) — write the test first, then implement the code to make it pass. Mocking / stubbing — replacing dependencies with controlled fake implementations. Code review best practice: always check whether tests cover both the happy and sad paths. A codebase with 90% test coverage can still have critical bugs if the coverage is concentrated on the happy path.
6 / 10
A developer submits a pull request containing a new feature for user authentication. During the code review, one reviewer comments: 'Looks good, but could you add a comment explaining why we're using this specific hashing algorithm?' What is the reviewer primarily asking for?
The reviewer is not criticizing the code's functionality but requesting an explanation of the *why* – why this particular hashing algorithm was chosen. This demonstrates the importance of documenting design decisions and ensuring understanding within the team, preventing future misinterpretations or potential security vulnerabilities. Options A and B represent different concerns; C is precisely what's being asked for here.
7 / 10
During a Slack conversation about a code review, a developer says: 'I'm not going to change this because it's already the way it is. It's been like this for years.' What does this statement likely represent in the context of code review?
This statement reflects a 'drive-by' comment – an observation or opinion offered without considering the merits of changing the existing code. It often indicates a reluctance to accept suggestions for improvement, even if those changes could enhance readability, maintainability, or security. The reviewer is likely frustrated by the lack of engagement.
8 / 10
A senior engineer is reviewing a pull request and writes: 'This code uses excessive recursion. Consider refactoring it into an iterative solution or using a queue to manage the state.' What technique is the reviewer suggesting?
The reviewer is suggesting an *algorithmic* change – a different approach to solving the problem. Excessive recursion can lead to stack overflow errors and performance issues. Suggesting an iterative solution or queue-based approach provides a more efficient and manageable way to handle state and control flow, directly addressing the core issue of the recursive implementation. This highlights the importance of considering alternative algorithms.
9 / 10
A developer is preparing a pull request description for a change to a REST API endpoint. They write: 'This endpoint now returns a 400 Bad Request if the input data is invalid.' What does '400 Bad Request' signify in this context?
The '400 Bad Request' HTTP status code explicitly indicates that the server received a valid request but was unable to process it because of incorrect or missing input data from the client. It's a standard response for API errors caused by malformed requests, not authorization issues (401) or server unavailability (503). This is crucial information for developers consuming the API.
10 / 10
A code reviewer comments: 'The implementation lacks proper error handling. It doesn't account for potential network timeouts or invalid responses from the external service.' What aspect of code quality is the reviewer primarily addressing?
The reviewer is focusing on *robustness*— the ability of the code to handle unexpected situations gracefully. Lack of error handling for network issues or invalid responses makes the application vulnerable to crashes and data corruption. Robust code anticipates potential failures and implements appropriate recovery mechanisms.
What does the "Code Review Language" vocabulary exercise cover?
This exercise tests real IT vocabulary related to code review language through 10 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 10 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — browse the full vocabulary exercises hub to find related modules covering adjacent IT topics and roles.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.