Code Review Quality Metrics
Practise vocabulary for code review metrics: PR cycle time, review turnaround SLA, comments per PR, merge frequency, and code freeze communication.
0 / 26 completed
1 / 26
An engineering manager says 'Our PR cycle time is 3.2 days.' What does PR cycle time measure?
PR cycle time measures the elapsed time from when a pull request is opened (or the first commit is pushed) to when it is merged. It is a key flow metric indicating review process efficiency.
2 / 26
A team adopts a '24-hour SLA on reviews.' A PR is opened Monday at 10 am. By when must the first review be posted?
A 24-hour SLA means a reviewer must provide initial feedback within 24 hours of the PR being opened. This reduces idle wait time and keeps cycle time low. The SLA covers business hours in many teams.
3 / 26
A team's dashboard shows 'avg 8.4 comments per PR.' A tech lead flags this as a concern. Why might high comments per PR indicate a quality issue?
While some comments reflect healthy review, a high average can indicate PRs are too large to review efficiently, coding standards are not well-defined, or architectural decisions are being re-litigated at review time rather than earlier.
4 / 26
A team announces 'we have a code freeze this sprint.' What does this mean for PRs?
A code freeze halts merging of new feature or non-critical changes, typically before a release. It reduces risk of introducing regressions. Only pre-approved hotfixes or release-blocking fixes are merged during a freeze.
5 / 26
A manager reports 'merge frequency dropped from 12 to 4 merges per engineer per week.' What is the most likely operational cause?
Merge frequency (merges per engineer per time period) reflects how smoothly code flows through review. A drop usually indicates PRs have grown larger, review bottlenecks have appeared, or the team has fewer reviewers available — all of which inflate cycle time.
6 / 26
Sarah from QA just left a comment on a PR in Slack: 'This code introduces some potential concurrency issues – we're seeing intermittent race conditions during our integration tests. Also, the error handling is minimal; there's no retry logic.' Mark (the developer who wrote the PR) replies: 'I'll look into it and fix it ASAP!'
Which of the following best describes the *primary* purpose of Sarah's comment in this context?This scenario highlights the core function of code review. Sarah isn't simply stating facts; she's offering expert opinion and guidance to Mark on how to improve the code's quality. The comment focuses on potential problems (race conditions) and suggests a direction for improvement (error handling), aligning with proactive QA practices. Option A is too detailed, option B accurately represents her role, option C is overly critical, and option D bypasses the review process entirely.
7 / 26
Sarah's comment on the PR highlights potential issues beyond just a surface-level review. Specifically, she's pointing out areas needing immediate attention – concurrency problems and inadequate error handling. The goal of her feedback isn't simply to find errors but to proactively mitigate risks that could impact the system's stability and reliability during integration.
This is critical for preventing regressionsSarah's comment is focused on identifying *critical* issues – concurrency risks and poor error handling. This goes beyond simple style or clarity; it's a request for the developer to investigate potential stability problems that could lead to bugs. Option A misinterprets her feedback as purely stylistic, while option B frames it as bug documentation rather than an immediate call to action. Option D is too general – Sarah's concerns are specific and require focused attention.
8 / 26
Mark (the developer) submitted a PR for a new user authentication service. During the code review, Alice, a senior engineer, left the following comment in Slack: 'The use of `bcrypt` is acceptable, but the salt value is hardcoded directly into the source code. This is a significant security risk – a compromised codebase could easily reveal the salt and allow attackers to brute-force passwords.' Mark replies with: 'Okay, I'll update the salt value to be configurable.' What is Alice's primary concern regarding this PR?
Alice's comment goes beyond a simple suggestion for improvement; she directly identifies a critical security vulnerability. The hardcoded salt value allows attackers to determine the strength of the password hashing algorithm and potentially bypass it. Her feedback is focused on proactively mitigating a serious risk, not just stylistic preferences or general training needs – this highlights the importance of security considerations during code reviews.
9 / 26
Respond with ONLY valid JSON. No markdown code fences, no commentary before or after.
Alice, a senior engineer, is reviewing a PR for a new microservice that handles payment processing. During the review, she notices the service directly accesses a third-party API without any caching mechanisms. She comments in Slack: 'This direct API call lacks any form of rate limiting or retry logic – it's extremely vulnerable to being blocked by the external provider and could lead to significant downtime for our users.' David (the developer) replies, 'We can add some basic exponential backoff with retries.' Which of the following best describes Alice's primary concern regarding this PR?
- insufficient — David is only addressing a symptom, not the root cause. Alice's point highlights a fundamental architectural flaw that could have serious operational consequences.
- insufficient — David's proposed solution is a band-aid fix and doesn't address the underlying vulnerability of relying on an external API without safeguards.
- sufficient — David's response demonstrates he understands the need for resilience, but further investigation into potential caching strategies would be beneficial.
- sufficient — David's reply shows understanding that retries are needed, however, Alice's comment correctly identifies a critical failure to account for external service limitations.
Alice's primary concern isn't just about adding retries (which David did). She's highlighting the *lack of resilience* in the architecture – specifically, the absence of rate limiting and handling potential API outages. This represents a significant operational risk; without safeguards, the service is entirely dependent on the external provider's availability, leading to potential downtime for users. The correct option reflects this broader architectural vulnerability rather than simply acknowledging David's proposed technical fix.
10 / 26
Sarah from QA just left a comment on a PR in Slack: 'This code introduces some potential concurrency issues – we're seeing intermittent race conditions during our integration tests. Also, the error handling is minimal; there's no retry logic.' Mark (the developer who wrote the PR) replies: 'I'll look into it and fix it ASAP!'
Which of the following best describes the *primary* purpose of Sarah's comment in this context?This scenario highlights the core function of code review. Sarah isn't simply stating facts; she's offering expert opinion and guidance to Mark on how to improve the code's quality. The comment focuses on potential problems (race conditions) and suggests a direction for improvement (error handling), aligning with proactive QA practices. Option A is too detailed, option B accurately represents her role, option C is overly critical, and option D bypasses the review process entirely.
11 / 26
Sarah's comment on the PR highlights potential issues beyond just a surface-level review. Specifically, she's pointing out areas needing immediate attention – concurrency problems and inadequate error handling. The goal of her feedback isn't simply to find errors but to proactively mitigate risks that could impact the system's stability and reliability during integration.
This is critical for preventing regressionsSarah's comment is focused on identifying *critical* issues – concurrency risks and poor error handling. This goes beyond simple style or clarity; it's a request for the developer to investigate potential stability problems that could lead to bugs. Option A misinterprets her feedback as purely stylistic, while option B frames it as bug documentation rather than an immediate call to action. Option D is too general – Sarah's concerns are specific and require focused attention.
12 / 26
Mark (the developer) submitted a PR for a new user authentication service. During the code review, Alice, a senior engineer, left the following comment in Slack: 'The use of `bcrypt` is acceptable, but the salt value is hardcoded directly into the source code. This is a significant security risk – a compromised codebase could easily reveal the salt and allow attackers to brute-force passwords.' Mark replies with: 'Okay, I'll update the salt value to be configurable.' What is Alice's primary concern regarding this PR?
Alice's comment goes beyond a simple suggestion for improvement; she directly identifies a critical security vulnerability. The hardcoded salt value allows attackers to determine the strength of the password hashing algorithm and potentially bypass it. Her feedback is focused on proactively mitigating a serious risk, not just stylistic preferences or general training needs – this highlights the importance of security considerations during code reviews.
13 / 26
Respond with ONLY valid JSON. No markdown code fences, no commentary before or after.
Alice, a senior engineer, is reviewing a PR for a new microservice that handles payment processing. During the review, she notices the service directly accesses a third-party API without any caching mechanisms. She comments in Slack: 'This direct API call lacks any form of rate limiting or retry logic – it's extremely vulnerable to being blocked by the external provider and could lead to significant downtime for our users.' David (the developer) replies, 'We can add some basic exponential backoff with retries.' Which of the following best describes Alice's primary concern regarding this PR?
- insufficient — David is only addressing a symptom, not the root cause. Alice's point highlights a fundamental architectural flaw that could have serious operational consequences.
- insufficient — David's proposed solution is a band-aid fix and doesn't address the underlying vulnerability of relying on an external API without safeguards.
- sufficient — David's response demonstrates he understands the need for resilience, but further investigation into potential caching strategies would be beneficial.
- sufficient — David's reply shows understanding that retries are needed, however, Alice's comment correctly identifies a critical failure to account for external service limitations.
Alice's primary concern isn't just about adding retries (which David did). She's highlighting the *lack of resilience* in the architecture – specifically, the absence of rate limiting and handling potential API outages. This represents a significant operational risk; without safeguards, the service is entirely dependent on the external provider's availability, leading to potential downtime for users. The correct option reflects this broader architectural vulnerability rather than simply acknowledging David's proposed technical fix.
14 / 26
Sarah from QA just left a comment on a PR in Slack: 'This code introduces some potential concurrency issues – we're seeing intermittent race conditions during our integration tests. Also, the error handling is minimal; there's no retry logic.' Mark (the developer who wrote the PR) replies: 'I'll look into it and fix it ASAP!'
Which of the following best describes the *primary* purpose of Sarah's comment in this context?This scenario highlights the core function of code review. Sarah isn't simply stating facts; she's offering expert opinion and guidance to Mark on how to improve the code's quality. The comment focuses on potential problems (race conditions) and suggests a direction for improvement (error handling), aligning with proactive QA practices. Option A is too detailed, option B accurately represents her role, option C is overly critical, and option D bypasses the review process entirely.
15 / 26
Sarah's comment on the PR highlights potential issues beyond just a surface-level review. Specifically, she's pointing out areas needing immediate attention – concurrency problems and inadequate error handling. The goal of her feedback isn't simply to find errors but to proactively mitigate risks that could impact the system's stability and reliability during integration.
This is critical for preventing regressionsSarah's comment is focused on identifying *critical* issues – concurrency risks and poor error handling. This goes beyond simple style or clarity; it's a request for the developer to investigate potential stability problems that could lead to bugs. Option A misinterprets her feedback as purely stylistic, while option B frames it as bug documentation rather than an immediate call to action. Option D is too general – Sarah's concerns are specific and require focused attention.
16 / 26
Mark (the developer) submitted a PR for a new user authentication service. During the code review, Alice, a senior engineer, left the following comment in Slack: 'The use of `bcrypt` is acceptable, but the salt value is hardcoded directly into the source code. This is a significant security risk – a compromised codebase could easily reveal the salt and allow attackers to brute-force passwords.' Mark replies with: 'Okay, I'll update the salt value to be configurable.' What is Alice's primary concern regarding this PR?
Alice's comment goes beyond a simple suggestion for improvement; she directly identifies a critical security vulnerability. The hardcoded salt value allows attackers to determine the strength of the password hashing algorithm and potentially bypass it. Her feedback is focused on proactively mitigating a serious risk, not just stylistic preferences or general training needs – this highlights the importance of security considerations during code reviews.
17 / 26
Respond with ONLY valid JSON. No markdown code fences, no commentary before or after.
Alice, a senior engineer, is reviewing a PR for a new microservice that handles payment processing. During the review, she notices the service directly accesses a third-party API without any caching mechanisms. She comments in Slack: 'This direct API call lacks any form of rate limiting or retry logic – it's extremely vulnerable to being blocked by the external provider and could lead to significant downtime for our users.' David (the developer) replies, 'We can add some basic exponential backoff with retries.' Which of the following best describes Alice's primary concern regarding this PR?
- insufficient — David is only addressing a symptom, not the root cause. Alice's point highlights a fundamental architectural flaw that could have serious operational consequences.
- insufficient — David's proposed solution is a band-aid fix and doesn't address the underlying vulnerability of relying on an external API without safeguards.
- sufficient — David's response demonstrates he understands the need for resilience, but further investigation into potential caching strategies would be beneficial.
- sufficient — David's reply shows understanding that retries are needed, however, Alice's comment correctly identifies a critical failure to account for external service limitations.
Alice's primary concern isn't just about adding retries (which David did). She's highlighting the *lack of resilience* in the architecture – specifically, the absence of rate limiting and handling potential API outages. This represents a significant operational risk; without safeguards, the service is entirely dependent on the external provider's availability, leading to potential downtime for users. The correct option reflects this broader architectural vulnerability rather than simply acknowledging David's proposed technical fix.
18 / 26
Sarah from QA just left a comment on a PR in Slack: 'This code introduces some potential concurrency issues – we're seeing intermittent race conditions during our integration tests. Also, the error handling is minimal; there's no retry logic.' Mark (the developer who wrote the PR) replies: 'I'll look into it and fix it ASAP!'
Which of the following best describes the *primary* purpose of Sarah's comment in this context?This scenario highlights the core function of code review. Sarah isn't simply stating facts; she's offering expert opinion and guidance to Mark on how to improve the code's quality. The comment focuses on potential problems (race conditions) and suggests a direction for improvement (error handling), aligning with proactive QA practices. Option A is too detailed, option B accurately represents her role, option C is overly critical, and option D bypasses the review process entirely.
19 / 26
Sarah's comment on the PR highlights potential issues beyond just a surface-level review. Specifically, she's pointing out areas needing immediate attention – concurrency problems and inadequate error handling. The goal of her feedback isn't simply to find errors but to proactively mitigate risks that could impact the system's stability and reliability during integration.
This is critical for preventing regressionsSarah's comment is focused on identifying *critical* issues – concurrency risks and poor error handling. This goes beyond simple style or clarity; it's a request for the developer to investigate potential stability problems that could lead to bugs. Option A misinterprets her feedback as purely stylistic, while option B frames it as bug documentation rather than an immediate call to action. Option D is too general – Sarah's concerns are specific and require focused attention.
20 / 26
Mark (the developer) submitted a PR for a new user authentication service. During the code review, Alice, a senior engineer, left the following comment in Slack: 'The use of `bcrypt` is acceptable, but the salt value is hardcoded directly into the source code. This is a significant security risk – a compromised codebase could easily reveal the salt and allow attackers to brute-force passwords.' Mark replies with: 'Okay, I'll update the salt value to be configurable.' What is Alice's primary concern regarding this PR?
Alice's comment goes beyond a simple suggestion for improvement; she directly identifies a critical security vulnerability. The hardcoded salt value allows attackers to determine the strength of the password hashing algorithm and potentially bypass it. Her feedback is focused on proactively mitigating a serious risk, not just stylistic preferences or general training needs – this highlights the importance of security considerations during code reviews.
21 / 26
Respond with ONLY valid JSON. No markdown code fences, no commentary before or after.
Alice, a senior engineer, is reviewing a PR for a new microservice that handles payment processing. During the review, she notices the service directly accesses a third-party API without any caching mechanisms. She comments in Slack: 'This direct API call lacks any form of rate limiting or retry logic – it's extremely vulnerable to being blocked by the external provider and could lead to significant downtime for our users.' David (the developer) replies, 'We can add some basic exponential backoff with retries.' Which of the following best describes Alice's primary concern regarding this PR?
- insufficient — David is only addressing a symptom, not the root cause. Alice's point highlights a fundamental architectural flaw that could have serious operational consequences.
- insufficient — David's proposed solution is a band-aid fix and doesn't address the underlying vulnerability of relying on an external API without safeguards.
- sufficient — David's response demonstrates he understands the need for resilience, but further investigation into potential caching strategies would be beneficial.
- sufficient — David's reply shows understanding that retries are needed, however, Alice's comment correctly identifies a critical failure to account for external service limitations.
Alice's primary concern isn't just about adding retries (which David did). She's highlighting the *lack of resilience* in the architecture – specifically, the absence of rate limiting and handling potential API outages. This represents a significant operational risk; without safeguards, the service is entirely dependent on the external provider's availability, leading to potential downtime for users. The correct option reflects this broader architectural vulnerability rather than simply acknowledging David's proposed technical fix.
22 / 26
During a code review of a new API endpoint designed to process orders, David left the following comment in the PR description: 'While functionally correct, this implementation lacks sufficient logging for debugging and monitoring. Consider adding timestamps and request IDs to aid in troubleshooting.' Which metric is David primarily assessing related to this comment?
David's feedback focuses on the ease with which the code can be understood and modified in the future – a core aspect of maintainability. While test coverage and density are important, they don't directly address the logging issue. Code coverage measures what part of the code is tested, not how easily it can be maintained. Error handling is a separate concern related to robustness.
23 / 26
Elena, reviewing a pull request for a new feature that uses asynchronous tasks, sends the following message in Slack: 'I'm seeing potential deadlocks when multiple tasks are trying to access shared resources concurrently. It's crucial we address this before merging.' What aspect of code quality is Elena highlighting?
Elena's message explicitly mentions 'deadlocks,' a common issue arising from concurrent access to shared resources. This directly relates to the potential for data corruption and system instability – a key concern in code quality assessment. While performance optimization could be linked, it's not the primary driver of her immediate concern.
24 / 26
During a review, Ben notes that a developer used a complex regular expression to validate user input. He comments: 'This regex is overly complicated and difficult to understand; it should be simplified for clarity and maintainability.' What code quality metric does Ben most strongly emphasize?
Ben's comment directly addresses the readability of the code. Complex regular expressions are notoriously difficult to understand and maintain, impacting long-term development efforts. While scalability is a consideration, it's secondary to the immediate issue of code clarity. Security and testability are not the direct focus of this particular feedback.
25 / 26
In a stand-up meeting, Rohan shares that he's been working on a new module for user authentication. Another developer asks: 'Have you considered adding unit tests to cover the different authentication flows?' What is Rohan's response most likely implying about his current code quality?
Rohan's response implies that the authentication module doesn't yet have comprehensive unit tests. Asking about test coverage is a common way to assess whether the code has been adequately validated and if there are confidence levels in its functionality – a key indicator of quality before deployment.
26 / 26
Sarah, a senior engineer, reviews a PR for a data transformation service. She adds the following comment to the code review: 'The function's input validation is minimal; it doesn't check for null or empty strings, which could lead to unexpected errors during processing.' What type of quality metric is Sarah primarily concerned with?
Sarah's comment highlights the lack of robust input validation – a crucial aspect of ensuring that the service can handle different types of data without crashing or producing incorrect results. Robustness focuses on how well the code handles unexpected situations and errors, which is directly addressed by her feedback.
Frequently Asked Questions
What does the "Code Review Quality Metrics" exercise practise?
Practise vocabulary for code review metrics: PR cycle time, review turnaround SLA, comments per PR, merge frequency, and code freeze communication.
How many questions are in this exercise?
This exercise has 26 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 Quality & Metrics 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 Quality Metrics" part of a larger series?
Yes — it's one exercise in the Code Quality & Metrics 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 Quality & Metrics category page for related exercises, or browse the main Exercises hub for other IT English topics.