iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
More review comments do not prove that code review creates code smells. But treating every valid comment as a change that must be made can add complexity, widen a patch, and leave future maintainers with machinery whose benefit is smaller than its cost.
How a correct review comment can still lead to a worse change
Mei Hammer describes a project review that produced 68 comments across 10 rounds, followed by 62 fixes. In the author’s account, successive, locally reasonable changes accumulated lasting complexity to address an edge case considered extremely unlikely. “The reviewer was not wrong once. That turned out to be the problem,” Hammer writes about that experience. This is a first-person account, not an independently verified case study. Read Hammer’s account.
The distinction is between identifying something real and deciding it is worth changing now. A comment can be technically correct while its suggested fix carries more implementation and maintenance cost than the risk it removes. If a team treats each comment as a required edit, review can become a chain: one edit creates new code or assumptions, which invite further comments and more edits.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What the evidence says—and what it cannot establish
Smelly pull requests receive more review discussion, but causation is unproven
A 2024 exploratory study examined pull requests in 25 Java projects, looking for four smell types: god class, data class, long method, and long parameter list. It classified 37.1% of accepted PRs and 44.8% of rejected PRs in its dataset as smelly, and reported more discussion and review comments in smelly PRs. Those figures describe that dataset, not all software projects. The association does not show that review caused the smells; complexity or difficulty understanding the code may help explain why those PRs attracted more discussion. See the study, “Code smells in pull requests: An exploratory study.”
#1 Best Overall
The study authors also note that smell detection is subjective: “code smells are not formally defined, and the interpretation can vary from one developer’s intuition to another.” A smell is therefore a signal to investigate, not a definitive verdict that a particular change is harmful.
Combining smell signals may help, but the evidence is limited
A 2018 quasi-experiment involving 11 professional developers found that 36.36% identified more design problems when considering multiple smells together, while 63.63% reported fewer false positives. The study also found that analyzing such locations can be difficult and time-consuming without prioritization and visualization support. Its small participant group and study task limit how far the results can be generalized. Read the study on identifying design problems in “stinky” code.
Rank #2
A practical way to decide whether a review fix is worthwhile
Hammer proposes weighing a finding’s likely user impact and frequency against both the immediate cost of the change and its continuing maintenance burden. The point is not to pretend those values are precise: make assumptions visible, discuss uncertainty, and distinguish a worthwhile improvement from a technically valid observation. The author says the triage questions and thresholds were refined by argument rather than measured outcomes; the complete routine has not been validated on live work with known results. The proposed approach and its qualifications are described in the article.
- State the observation separately from the proposed fix. What behavior, risk, or design issue does the reviewer see? Is the suggested edit the only way to address it?
- Estimate user impact and likelihood. Who could be affected, how seriously, and how often might the situation occur? Record assumptions rather than presenting an estimate as measured fact.
- Count the full cost of the fix. Consider not only implementation and testing, but also new branches, abstractions, configuration, dependencies, or future maintenance the change introduces.
- Compare the trade-off and choose a scope. Fix now when the expected benefit justifies the cost; otherwise, document the concern, defer it, or leave the code unchanged. Keep unrelated cleanup from expanding the patch.
- Reassess after each review round. Ask whether the latest edit created a new risk or prompted another fix, and whether the chain still addresses the original concern.
For example, Hammer’s article illustrates a possible configuration-key collision with an estimated frequency of 0.01 incidents per year and a maintenance burden of 0.5 hours per year. These are the author’s illustrative estimates, not measured incident or labor rates. Their value is in making the trade-off explicit, not in treating the numbers as a general benchmark.
Rank #3
Look for fix chains, not just review volume
Counting comments or review rounds alone cannot tell a team whether its process is generating unnecessary complexity. A more focused question is whether later comments repeatedly land on code altered in response to earlier comments. Hammer describes a script called chain-check intended to identify comments on code changed after previous review rounds. The author reports finding defects in an earlier version and revising its logic; this is an author-reported tool account, not an independent evaluation. See the script discussion in the original article.
- Track whether a comment identifies a defect or requests a preference, and whether the proposed change is necessary to resolve it.
- When edits trigger more review findings, check whether the new findings are independent problems or consequences of growing scope.
- Use chain detection as a prompt for human review, not proof that a comment or fix was wrong.
- Evaluate any process change against live work and known outcomes before treating it as effective.
What teams can reasonably conclude
The available evidence supports a cautious conclusion: smelly PRs can attract more review discussion, and review comments can lead to consequential edits, but the studies do not establish that code review creates smells. The practical safeguard is to keep the decision to change separate from the decision that a comment is correct. Estimate benefit and likelihood openly, account for maintenance and scope, and watch for chains across rounds. Treat the proposed triage routine and script as ideas to evaluate—not proven guarantees.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
