Intermediate
Code Review
#vocabulary
#nit
#DRY
#code-smell
Code Review Vocabulary
4 exercises — master the vocabulary you need to understand and participate in professional code reviews.
0 / 24 completed
1 / 24
In a code review, what does the prefix nit: signal?
Nit (short for nitpick) is one of the most common code review prefixes. It signals: "this is a minor preference — feel free to ignore it." Examples:
Other standard prefixes:
• blocking: — must be fixed before merge
• suggestion: — take it or leave it
• question: — asking for clarification, not requesting a change
• FYI: — informational only
• optional: — same as nit but more explicit
Using these prefixes reduces friction in code reviews enormously — the author immediately knows whether they need to act.
nit: variable name could be more descriptive, nit: missing trailing comma.Other standard prefixes:
• blocking: — must be fixed before merge
• suggestion: — take it or leave it
• question: — asking for clarification, not requesting a change
• FYI: — informational only
• optional: — same as nit but more explicit
Using these prefixes reduces friction in code reviews enormously — the author immediately knows whether they need to act.
2 / 24
A reviewer writes: "happy path only — what about error cases?"
What does "happy path" mean in this context?
What does "happy path" mean in this context?
"Happy path" refers to the scenario where every input is valid, every service responds correctly, and nothing unexpected happens. Code that only handles the happy path has no error handling — it breaks when anything goes wrong.
The reviewer is flagging a gap: "I see tests/logic for the success case, but nothing for: empty input, null values, API timeout, invalid format, concurrent modifications," etc.
Related terms: sad path (error/failure scenarios), edge case (unusual but valid input), corner case (extreme or rare input at the boundary of valid input space). A production-ready implementation handles both the happy path and the sad paths.
The reviewer is flagging a gap: "I see tests/logic for the success case, but nothing for: empty input, null values, API timeout, invalid format, concurrent modifications," etc.
Related terms: sad path (error/failure scenarios), edge case (unusual but valid input), corner case (extreme or rare input at the boundary of valid input space). A production-ready implementation handles both the happy path and the sad paths.
3 / 24
What does DRY mean when a reviewer comments "this violates DRY"?
DRY = Don't Repeat Yourself, one of the most cited software engineering principles. When a reviewer says "this violates DRY", they mean the same logic, string, or computation appears in multiple places — which creates a maintenance problem (if you change the logic, you need to change it everywhere).
The fix is usually: extract the repeated code into a function, constant, or component. Example: if the same date formatting logic appears in 4 components, extract it to
Related principles reviewers often mention:
• KISS — Keep It Simple, Stupid (don't over-engineer)
• YAGNI — You Ain't Gonna Need It (don't add features you don't have a use case for yet)
• SRP — Single Responsibility Principle (each function / class should do one thing)
The fix is usually: extract the repeated code into a function, constant, or component. Example: if the same date formatting logic appears in 4 components, extract it to
formatDate().Related principles reviewers often mention:
• KISS — Keep It Simple, Stupid (don't over-engineer)
• YAGNI — You Ain't Gonna Need It (don't add features you don't have a use case for yet)
• SRP — Single Responsibility Principle (each function / class should do one thing)
4 / 24
A reviewer writes: "This looks like a code smell — the function is doing too many things." What is a code smell?
Code smell is a term coined by Martin Fowler. It describes code that suggests a problem — not a definite bug, but a warning sign that something may be wrong with the design. The term is deliberately informal — you "smell" something off in the code.
Common code smells reviewers mention:
• Long method — a function that does too many things (what the reviewer flagged)
• God object — a class that knows/does too much
• Magic numbers — unexplained hardcoded values (
• Dead code — unused variables, functions, imports
• Primitive obsession — using primitives (strings, ints) where a domain object should be used
• Feature envy — a method that uses another class's data more than its own
Common code smells reviewers mention:
• Long method — a function that does too many things (what the reviewer flagged)
• God object — a class that knows/does too much
• Magic numbers — unexplained hardcoded values (
if (status === 3) — what is 3?)• Dead code — unused variables, functions, imports
• Primitive obsession — using primitives (strings, ints) where a domain object should be used
• Feature envy — a method that uses another class's data more than its own
5 / 24
John writes a PR description for a new API endpoint: 'Implemented the user profile update. Handles name and email changes. Returns success status code 200 on successful updates.' A senior developer comments: 'Could you add input validation to prevent invalid email formats? Also, consider logging these changes for auditing purposes.' What does 'logging these changes for auditing purposes' refer to in this context?The comment about 'logging these changes for auditing purposes' isn't simply tracking the API call itself. It refers to a proactive method of recording detailed information *about* that API call – specifically, the details of the user profile update (name and email) – in a way that can be examined later to understand what happened, troubleshoot issues, or demonstrate compliance with regulations. This contrasts with option A which describes data verification; option C is an incorrect interpretation of error correction; and option D refers to broader regulatory compliance rather than specific logging practices.
6 / 24
Sarah: 'The tests are failing intermittently. I've run them multiple times, and they seem to pass now.'
Mark: 'Can you provide the full stack trace?'
What does Mark likely mean by requesting a 'full stack trace' during a code review?A 'full stack trace' provides critical debugging information. It reveals the precise chain of function calls that occurred when the error happened, including the file name and line number where the error originated. This is far more useful than simply seeing test failures; it allows developers to precisely identify the root cause of the issue and debug effectively. The other options represent misunderstandings about what a stack trace provides.
7 / 24
During a code review of a new microservice designed to process payments, a developer submits a pull request with the following description: 'Added logic for handling recurring subscriptions. Implemented tokenization using Stripe's API. Returns transaction ID on success.' A senior engineer responds: 'I'm seeing some high latency when processing these transactions – could you profile this further?' What does the engineer likely mean by asking to 'profile this further'?
Profiling refers to using specialized tools to examine the internal workings of a system – in this case, the microservice – to pinpoint areas causing performance issues. The engineer isn't simply asking for more comments or database optimization; they're requesting detailed data about how the code *actually* executes and where time is being spent. A profiler would reveal whether the Stripe API calls are slow, if there are inefficient loops in the recurring subscription logic, or if other processes are impacting performance. This allows for targeted improvements rather than guesswork.
8 / 24
David writes a comment on a PR: 'This function is tightly coupled to the database. We should consider using an ORM to improve maintainability and reduce coupling.' What does tightly coupled mean in this context?
Tightly coupled refers to a situation where two pieces of code are interdependent in a way that makes them difficult to modify or reuse independently. In this case, David is highlighting that the function's reliance on the database implementation creates a strong dependency, hindering future changes and making testing more complex – this is a common concern when discussing design choices during code reviews.
9 / 24
Alice writes a Slack message to her team: 'Just finished refactoring the user authentication module. Added unit tests and improved error handling.'
Bob replies: 'Sounds good! Can you provide a link to the updated API documentation?'
What does Bob likely mean by requesting the 'updated API documentation' in this context?Bob is requesting the updated API documentation to ensure that the changes made by Alice align with the existing system and don't introduce any compatibility issues. This reflects best practices for code reviews – verifying that modifications integrate correctly and maintain functionality. The other options are less likely; Alice hasn't requested a demo, nor is Bob checking coding standards directly, and asking for confirmation isn't specific enough.10 / 24
John writes a PR description for a new API endpoint: 'Implemented the user profile update. Handles name and email changes. Returns success status code 200 on successful updates.' A senior developer comments: 'Could you add input validation to prevent invalid email formats? Also, consider logging these changes for auditing purposes.' What does 'logging these changes for auditing purposes' refer to in this context?The comment about 'logging these changes for auditing purposes' isn't simply tracking the API call itself. It refers to a proactive method of recording detailed information *about* that API call – specifically, the details of the user profile update (name and email) – in a way that can be examined later to understand what happened, troubleshoot issues, or demonstrate compliance with regulations. This contrasts with option A which describes data verification; option C is an incorrect interpretation of error correction; and option D refers to broader regulatory compliance rather than specific logging practices.
11 / 24
Sarah: 'The tests are failing intermittently. I've run them multiple times, and they seem to pass now.'
Mark: 'Can you provide the full stack trace?'
What does Mark likely mean by requesting a 'full stack trace' during a code review?A 'full stack trace' provides critical debugging information. It reveals the precise chain of function calls that occurred when the error happened, including the file name and line number where the error originated. This is far more useful than simply seeing test failures; it allows developers to precisely identify the root cause of the issue and debug effectively. The other options represent misunderstandings about what a stack trace provides.
12 / 24
During a code review of a new microservice designed to process payments, a developer submits a pull request with the following description: 'Added logic for handling recurring subscriptions. Implemented tokenization using Stripe's API. Returns transaction ID on success.' A senior engineer responds: 'I'm seeing some high latency when processing these transactions – could you profile this further?' What does the engineer likely mean by asking to 'profile this further'?
Profiling refers to using specialized tools to examine the internal workings of a system – in this case, the microservice – to pinpoint areas causing performance issues. The engineer isn't simply asking for more comments or database optimization; they're requesting detailed data about how the code *actually* executes and where time is being spent. A profiler would reveal whether the Stripe API calls are slow, if there are inefficient loops in the recurring subscription logic, or if other processes are impacting performance. This allows for targeted improvements rather than guesswork.
13 / 24
David writes a comment on a PR: 'This function is tightly coupled to the database. We should consider using an ORM to improve maintainability and reduce coupling.' What does tightly coupled mean in this context?
Tightly coupled refers to a situation where two pieces of code are interdependent in a way that makes them difficult to modify or reuse independently. In this case, David is highlighting that the function's reliance on the database implementation creates a strong dependency, hindering future changes and making testing more complex – this is a common concern when discussing design choices during code reviews.
14 / 24
Alice writes a Slack message to her team: 'Just finished refactoring the user authentication module. Added unit tests and improved error handling.'
Bob replies: 'Sounds good! Can you provide a link to the updated API documentation?'
What does Bob likely mean by requesting the 'updated API documentation' in this context?Bob is requesting the updated API documentation to ensure that the changes made by Alice align with the existing system and don't introduce any compatibility issues. This reflects best practices for code reviews – verifying that modifications integrate correctly and maintain functionality. The other options are less likely; Alice hasn't requested a demo, nor is Bob checking coding standards directly, and asking for confirmation isn't specific enough.15 / 24
John writes a PR description for a new API endpoint: 'Implemented the user profile update. Handles name and email changes. Returns success status code 200 on successful updates.' A senior developer comments: 'Could you add input validation to prevent invalid email formats? Also, consider logging these changes for auditing purposes.' What does 'logging these changes for auditing purposes' refer to in this context?The comment about 'logging these changes for auditing purposes' isn't simply tracking the API call itself. It refers to a proactive method of recording detailed information *about* that API call – specifically, the details of the user profile update (name and email) – in a way that can be examined later to understand what happened, troubleshoot issues, or demonstrate compliance with regulations. This contrasts with option A which describes data verification; option C is an incorrect interpretation of error correction; and option D refers to broader regulatory compliance rather than specific logging practices.
16 / 24
Sarah: 'The tests are failing intermittently. I've run them multiple times, and they seem to pass now.'
Mark: 'Can you provide the full stack trace?'
What does Mark likely mean by requesting a 'full stack trace' during a code review?A 'full stack trace' provides critical debugging information. It reveals the precise chain of function calls that occurred when the error happened, including the file name and line number where the error originated. This is far more useful than simply seeing test failures; it allows developers to precisely identify the root cause of the issue and debug effectively. The other options represent misunderstandings about what a stack trace provides.
17 / 24
During a code review of a new microservice designed to process payments, a developer submits a pull request with the following description: 'Added logic for handling recurring subscriptions. Implemented tokenization using Stripe's API. Returns transaction ID on success.' A senior engineer responds: 'I'm seeing some high latency when processing these transactions – could you profile this further?' What does the engineer likely mean by asking to 'profile this further'?
Profiling refers to using specialized tools to examine the internal workings of a system – in this case, the microservice – to pinpoint areas causing performance issues. The engineer isn't simply asking for more comments or database optimization; they're requesting detailed data about how the code *actually* executes and where time is being spent. A profiler would reveal whether the Stripe API calls are slow, if there are inefficient loops in the recurring subscription logic, or if other processes are impacting performance. This allows for targeted improvements rather than guesswork.
18 / 24
David writes a comment on a PR: 'This function is tightly coupled to the database. We should consider using an ORM to improve maintainability and reduce coupling.' What does tightly coupled mean in this context?
Tightly coupled refers to a situation where two pieces of code are interdependent in a way that makes them difficult to modify or reuse independently. In this case, David is highlighting that the function's reliance on the database implementation creates a strong dependency, hindering future changes and making testing more complex – this is a common concern when discussing design choices during code reviews.
19 / 24
Alice writes a Slack message to her team: 'Just finished refactoring the user authentication module. Added unit tests and improved error handling.'
Bob replies: 'Sounds good! Can you provide a link to the updated API documentation?'
What does Bob likely mean by requesting the 'updated API documentation' in this context?Bob is requesting the updated API documentation to ensure that the changes made by Alice align with the existing system and don't introduce any compatibility issues. This reflects best practices for code reviews – verifying that modifications integrate correctly and maintain functionality. The other options are less likely; Alice hasn't requested a demo, nor is Bob checking coding standards directly, and asking for confirmation isn't specific enough.20 / 24
John writes a PR description for a new API endpoint: 'Implemented the user profile update. Handles name and email changes. Returns success status code 200 on successful updates.' A senior developer comments: 'Could you add input validation to prevent invalid email formats? Also, consider logging these changes for auditing purposes.' What does 'logging these changes for auditing purposes' refer to in this context?The comment about 'logging these changes for auditing purposes' isn't simply tracking the API call itself. It refers to a proactive method of recording detailed information *about* that API call – specifically, the details of the user profile update (name and email) – in a way that can be examined later to understand what happened, troubleshoot issues, or demonstrate compliance with regulations. This contrasts with option A which describes data verification; option C is an incorrect interpretation of error correction; and option D refers to broader regulatory compliance rather than specific logging practices.
21 / 24
Sarah: 'The tests are failing intermittently. I've run them multiple times, and they seem to pass now.'
Mark: 'Can you provide the full stack trace?'
What does Mark likely mean by requesting a 'full stack trace' during a code review?A 'full stack trace' provides critical debugging information. It reveals the precise chain of function calls that occurred when the error happened, including the file name and line number where the error originated. This is far more useful than simply seeing test failures; it allows developers to precisely identify the root cause of the issue and debug effectively. The other options represent misunderstandings about what a stack trace provides.
22 / 24
During a code review of a new microservice designed to process payments, a developer submits a pull request with the following description: 'Added logic for handling recurring subscriptions. Implemented tokenization using Stripe's API. Returns transaction ID on success.' A senior engineer responds: 'I'm seeing some high latency when processing these transactions – could you profile this further?' What does the engineer likely mean by asking to 'profile this further'?
Profiling refers to using specialized tools to examine the internal workings of a system – in this case, the microservice – to pinpoint areas causing performance issues. The engineer isn't simply asking for more comments or database optimization; they're requesting detailed data about how the code *actually* executes and where time is being spent. A profiler would reveal whether the Stripe API calls are slow, if there are inefficient loops in the recurring subscription logic, or if other processes are impacting performance. This allows for targeted improvements rather than guesswork.
23 / 24
David writes a comment on a PR: 'This function is tightly coupled to the database. We should consider using an ORM to improve maintainability and reduce coupling.' What does tightly coupled mean in this context?
Tightly coupled refers to a situation where two pieces of code are interdependent in a way that makes them difficult to modify or reuse independently. In this case, David is highlighting that the function's reliance on the database implementation creates a strong dependency, hindering future changes and making testing more complex – this is a common concern when discussing design choices during code reviews.
24 / 24
Alice writes a Slack message to her team: 'Just finished refactoring the user authentication module. Added unit tests and improved error handling.'
Bob replies: 'Sounds good! Can you provide a link to the updated API documentation?'
What does Bob likely mean by requesting the 'updated API documentation' in this context?Bob is requesting the updated API documentation to ensure that the changes made by Alice align with the existing system and don't introduce any compatibility issues. This reflects best practices for code reviews – verifying that modifications integrate correctly and maintain functionality. The other options are less likely; Alice hasn't requested a demo, nor is Bob checking coding standards directly, and asking for confirmation isn't specific enough.Frequently Asked Questions
What does the "Code Review Vocabulary" exercise practise?
Master key code review terms: nit, happy path, DRY, code smell, LGTM, blocking, SRP. 4 vocabulary exercises with detailed explanations.
How many questions are in this exercise?
This exercise has 24 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Intermediate. If the vocabulary feels difficult, browse the Code Review Language category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "Code Review Vocabulary" part of a larger series?
Yes — it's one exercise in the Code Review Language category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Code Review Language category page for related exercises, or browse the main Exercises hub for other IT English topics.