Code Smells Are Not Subjective: How to Make Your Review Objective

Fewer than 25% of changes at Google had more than one reviewer, and more than 80% finished in a single iteration (Modern Code Review: A Case Study at Google). That's the data from the largest code review study we have, and it tells us something important: code review doesn't have to be a slog. But for many teams, it is. Why? Because we let code smells become subjective—'I don't like this function'—instead of measurable. We're going to fix that.

Imagine You're the Reviewer

Picture this: you're a senior developer on a team of eight. A junior dev, Priya, opens a pull request that adds a new REST endpoint to your Python backend. It's 350 lines of new code, plus tests. You get a notification, and your first instinct is to open the diff and start commenting on style—maybe you'd rename a variable or two. But that's a trap. Google's own guidance says the most important thing to cover is the overall design, not the nits (Google Engineering Practices). So instead, you take a breath and follow a structured approach.

Start with the Numbers

Before you even read the code, you run the static analysis suite. You've got SonarQube set up, and it gives you a quick read: the new code has a cyclomatic complexity of 8 in one function, and the technical debt ratio is at 4.2%. That's a solid A rating (SonarQube). But you also notice a security hotspot flagged by Bandit—a potential SQL injection in a query string. That's a blocker. You're not going to approve this until it's fixed. The numbers give you an objective starting point: the design is okay, but security is non-negotiable. You can point to the Bandit output and say, 'This is a real vulnerability, here's the line.'

Size Matters: The 400-Line Rule

Next, you look at the size. Google's research found that the median change at Google was about 24 lines, and over 90% of changes touched fewer than 10 files (Modern Code Review). This PR is 350 lines across 6 files—that's on the edge. Google's practical guidance suggests keeping changes under 400-500 lines of meaningful change, and splitting larger ones by concern (Google Engineering Practices). You think: this is a single endpoint, so it's arguably one concern. But you'd rather have seen it split into a model change and a view change. Still, it's within the limit, so you proceed.

The Review: Design First, Then Details

You start with the overall design. The endpoint does input validation, but you notice it doesn't check for broken access control—the OWASP Top 10's #1 risk for 2025 (OWASP). You comment: 'This endpoint should verify the user has permission to access the resource. See A01.' That's a blocking comment. Next, you look at the error handling. The code catches an exception and returns a generic 500, but it doesn't log the details. That's a new category in OWASP 2025: A10 Mishandling of Exceptional Conditions (OWASP). You add a suggestion: 'Log the exception with context, and return a safe message.'

Now you're into the nitty-gritty. You use the review comments technique from Google: label each comment as nit, suggestion, or blocking, and be specific with file paths and line numbers (Google Engineering Practices). You list:

• Blocking: Fix the SQL injection in `query.py:42`.
• Suggestion: Add a permission check in `views.py:15`.
• Nit: Use a constant for the timeout value in `client.py:88`.

You also notice that the function `parse_response` has a cyclomatic complexity of 8—that's not terrible, but SonarQube's metric suggests it's on the edge. You suggest breaking it into two smaller functions, but you're not going to block on it. Your standard is Google's: approve if it definitely improves the overall code health, even if it's not perfect (Google Engineering Practices).

Automation and the Quality Gate

You're lucky that your CI is set up with a quality gate. SonarQube's built-in 'Sonar way' gate has four conditions: no new issues, all security hotspots reviewed, new coverage ≥80%, and duplication ≤3% (SonarQube). The gate fails because the coverage is only 74% on the new code. That's objective. You don't have to argue about it—the gate says no merge until coverage improves. This is exactly how you make code smells objective: let the tool enforce the threshold. You add a comment pointing to the SonarQube report, and Priya knows exactly what to do.

Speed and Communication

Google says the maximum time to respond to a review request is one business day—first thing next morning (Google Engineering Practices). You respond within two hours. That's important because quick responses ease frustration (Google Engineering Practices). You use the 'LGTM with comments' technique: you approve the PR conditionally, with the blocking comments to be addressed, because you trust Priya will fix them (Google Engineering Practices). You write: 'LGTM with comments—please fix the SQL injection and the permission check, then ping me.' That way, the review doesn't stall.

What I'd Actually Do

Here's my concrete recommendation: make code review objective by leaning on three things. First, set up a quality gate that blocks merge on security vulnerabilities and coverage below 80%—that's non-negotiable. Second, keep PRs small, ideally under 400 lines, and split by concern. Third, when you review, start with the design and use static analysis metrics like cyclomatic complexity and technical debt ratio to guide your comments, not personal taste. Remember: the goal is to improve overall code health, and there's no such thing as perfect code (Google Engineering Practices). If you do this, you'll stop arguing about subjective taste and start improving your codebase measurably. And you'll be done in one iteration, like 80% of reviews at Google.

Sources

• Google Engineering Practices (code review) - https://google.github.io/eng-practices/review/
• Modern Code Review: A Case Study at Google (ICSE-SEIP '18) - https://www.papercache.org/papers/mlsys/system/2026/03/25/modern-code-review-a-case-study-at-google
• SonarQube Server Docs - Quality Gates - https://docs.sonarsource.com/sonarqube-server/2026.1/quality-standards-administration/managing-quality-gates/introduction-to-quality-gates
• OWASP Top Ten 2025 - https://owasp.org/Top10/2025/0x00_2025-Introduction/
• Bandit (PyCQA) Docs - https://bandit.readthedocs.io/en/latest/