Code Review Examples: Before-and-After Walkthroughs

A high-quality code review example turns vague, frustrating feedback into clear, actionable guidance, and the following before-and-after walkthroughs demonstrate how. By anchoring comments to specific code lines, explaining the rationale, and proposing concrete fixes, reviewers accelerate development, reduce defects, and lift team confidence. Google's Engineering Practices documentation advocates this structured approach as a way to improve code health over time, but it does not present empirical data showing that teams adopting it resolve feedback faster or ship healthier code.

Modern engineering teams repeatedly prove that well-structured code review examples shorten cycle time, shrink bug counts, and boost developer morale. In the following side-by-side walkthroughs, you'll see precisely how targeted, constructive feedback outperforms blanket statements such as "This is confusing."

Why Specific, Actionable Feedback Transforms Code Review Quality

Atlassian's analysis of 5,000 review comments shows that vague feedback, such as "This is confusing," leads to ineffective reviews, while specific suggestions with code snippets and clear explanations drive productive interactions. Some code review best-practice guides suggest that effective comments explain the "why," offer precise alternatives, and focus on code impact rather than personal critique, but this specific formulation is not stated in Google's official Engineering Practices.

Consider the difference between "This variable name is terrible" and "Could we rename data to userProfiles for clarity when revisiting this code?" The latter accelerates development and preserves team trust, whereas the former stalls progress. Graphite's code review best-practices guide echoes this: actionable feedback plus rationale equals faster resolution and higher code quality.

This guide provides concrete code review examples across Python, Java, and TypeScript, including paired feedback transformations, language-specific snippets, and common anti-patterns. Every sample is grounded in Google's Engineering Practices, official language docs, and authoritative blogs like Baeldung, Real Python, Microsoft, DoorDash Engineering, and GitHub Engineering.

When you layer comprehensive dependency analysis onto your workflow, reviewers can immediately see cross-file impacts and hidden side effects, catching issues that traditional diff-only tools miss. Teams implementing static code analysis alongside manual reviews catch 40% more defects before merge.

Explore how Context Engine identifies review-relevant code patterns →

What Separates a Good Code Review Example from a Poor One?

Good feedback answers three questions: what needs attention, why it matters, and how to fix it. Poor feedback misses at least one of these.

The Transformation Pattern

The following table illustrates how vague comments can be restructured into specific, actionable guidance that developers can immediately apply.

Google's Engineering Practices are sometimes paraphrased as encouraging reviewers to explain not just what is wrong, but why it is wrong, what the implications are, and potentially how to fix it, although this wording does not appear in the official documentation.

Severity Labeling System

Labeling comment severity ("Nit," "Optional," "Critical," "FYI") helps authors prioritize. Google and the Conventional Comments spec recommend explicit prefixes so reviewers' intent is unambiguous:

• Nit: Minor suggestion; not blocking
• Optional: Nice-to-have; improves code but not required
• Critical: Must be fixed before merge
• FYI: Context only; no action required

For example:

Critical: This endpoint accepts unsanitized user input that's directly interpolated into a SQL query, creating a SQL-injection vulnerability. Use parameterized queries instead. See guidelines: [link]

Nit: Consider renaming process() to validateUserInput() for clarity. Not blocking.

Python Code Review Examples

Python reviews often cover error handling, naming, performance, and security. The following examples demonstrate common issues and their idiomatic Python solutions. For teams looking to accelerate Python development, AI-powered code generation tools can help maintain consistency across reviews.

Error Handling: Embrace EAFP

The Python glossary defines EAFP (Easier to Ask for Forgiveness than Permission) as the preferred Python style over LBYL (Look Before You Leap).

Before (LBYL, fragile):

if os.path.exists(file_path):
    os.remove(file_path)
else:
    print(f"Error: file {file_path} does not exist!")

After (EAFP, robust):

try:
    os.remove(file_path)
except OSError as error:
    print(f"Error deleting file: {error}")

Naming: PEP 8 Compliance

PEP 8 specifies that function names should be lowercase with words separated by underscores.

Before:

def calcTotal(basePrice, taxRate=0.05):
    return basePrice * (1 + taxRate)

After:

def calculate_price_with_taxes(
    base_price: float, tax_rate: float = 0.05
) -> float:
    return base_price * (1 + tax_rate)

Performance: O(n) Set Deduplication

Before (O(n²)):

def remove_duplicates(items):
    unique_items = []
    for item in items:
        if item not in unique_items:
            unique_items.append(item)
    return unique_items

After (O(n)):

def remove_duplicates(items):
    return list(set(items))

Security: SQL Injection Prevention

The OWASP SQL Injection Prevention Cheat Sheet recommends parameterized queries as the primary defense.

Before:

def login(username, password):
    query = f"SELECT * FROM users WHERE username = '{username}'"
    cursor.execute(query)

After:

def get_user(username):
    query = "SELECT username, password FROM users WHERE username = ?"
    cursor.execute(query, (username,))
    return cursor.fetchone()

Java Code Review Examples

Java reviewers primarily focus on broader concerns like correctness, readability, maintainability, performance, security, and test coverage, with exception handling, SOLID principles, and null-related issues appearing only indirectly or occasionally. These examples highlight patterns that frequently surface during enterprise Java reviews.

Exception Handling: Try-With-Resources

Oracle's Java documentation recommends try-with-resources for automatic resource management.

Before (leak risk):

public int getPlayerScore(String playerFile) {
    try {
        Scanner contents = new Scanner(new File(playerFile));
        return Integer.parseInt(contents.nextLine());
    } catch (FileNotFoundException noFile) {
        throw new IllegalArgumentException("File not found");
    }
}

After (auto-close, robust):

public int getPlayerScore(String playerFile) {
    try (Scanner contents = new Scanner(new File(playerFile))) {
        return Integer.parseInt(contents.nextLine());
    } catch (FileNotFoundException e) {
        logger.warn("File not found, resetting score.");
        return 0;
    } catch (NumberFormatException e) {
        logger.warn("Player file corrupted!", e);
        return 0;
    }
}

SOLID: Single Responsibility Principle

Baeldung's SOLID guide explains that a class should have only one reason to change.

Before (violates SRP):

public class Book {
    /* … */    
    void printTextToConsole() { /* formatting and printing */ }
}

After (separated concerns):

public class Book { /* domain logic only */ }

public class BookPrinter {
    void printTextToConsole(String text) { /* printing */ }
}

See how comprehensive codebase analysis improves Java review accuracy →

Null Safety: Optional Chaining

Oracle's Optional documentation provides methods for handling potentially null values without nested conditionals.

Before (nested checks):

public static boolean isNearLocation(User user) {
    if (user != null) {
        if (user.getAddress() != null) {
            if (user.getAddress().getState() != null) {
                String zip = user.getAddress().getState().getPostalCode().getZip();
                if (zip != null) {
                    return storeZipCodes.contains(zip);
                }
            }
        }
    }
    return false;
}

After (streamlined):

public static boolean isNearPhysicalLocation(User user) {
    return Optional.ofNullable(user)
        .map(User::getAddress)
        .map(Address::getState)
        .map(State::getZip)
        .map(storeZipCodes::contains)
        .orElse(false);
}

TypeScript Code Review Examples

TypeScript documentation and common review guides focus on general type safety, strict compiler options, and avoiding any, rather than specifically emphasizing type narrowing, generic constraints, and async error handling as key review topics. The following walkthroughs address patterns that improve type safety and runtime reliability.

Type Narrowing: typeof Guards

The TypeScript Handbook on Narrowing explains how type guards refine types within conditional blocks.

Before (unsafe):

function padLeft(padding: number | string, input: string): string {
  if (typeof padding === "number") {
    return " ".repeat(padding) + input;
  }
  return padding + input;
}

(Compiler still warns in other branches.)

After (safe, same code but explained):

function padLeft(padding: number | string, input: string): string {
  if (typeof padding === "number") {
    return " ".repeat(padding) + input;  // padding is number here
  }
  return padding + input;               // padding is string here
}

Generic Constraints: keyof for Safety

The TypeScript Handbook on Generics demonstrates using keyof to constrain generic parameters.

Before:

function getProperty(obj: any, key: string) {
  return obj[key];
}

After:

function getProperty<Type, Key extends keyof Type>(
  obj: Type, 
  key: Key
): Type[Key] {
  return obj[key];
}

Async/Await: Proper Error Handling

Before (unhandled):

async function fetchUserData(id: string) {
  const response = await fetch(`/api/users/${id}`);
  return response.json();
}

After (robust):

async function fetchUserData(id: string): Promise<User> {
  try {
    const response = await fetch(`/api/users/${id}`);

    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`);
    }

    return await response.json();
  } catch (error) {
    console.error('Error fetching user:', error);
    throw error;
  }
}

Inline Commentary Techniques

A standardized prefix system (praise, nit, suggestion, issue, question, thought, note, chore) removes ambiguity. The Conventional Comments specification defines each prefix and provides usage examples.

Question-based comments engage developers:

✅ "Could you help me understand why we're using approach X here?"
❌ "You should do Y."

Common Anti-Patterns and Their Corrections

Recognizing unproductive feedback patterns helps reviewers avoid them. The following examples show how to transform common anti-patterns into constructive guidance. Teams focused on code quality metrics can use these patterns to improve review effectiveness.

1. Vague Criticism

• Before: "This code is confusing."
• After: "This function handles auth, validation, and logging. Extracting validation into validateUserInput() could improve readability and testability."

1. Demanding Perfection

• Before: "This violates SRP. Refactor."
• After: "Current implementation works. If we add more payment types later, a factory pattern will ease extension; worth considering, but non-blocking for this PR."

1. Knowledge Gatekeeping

• Before: "This violates the principle we discussed."
• After: Detailed explanation, risks, and suggested alternative, inviting team discussion.

What to Do Next

Effective feedback demands more than spotting flaws. Google's Engineering Practices do not contain an explicit directive telling reviewers to "explain not just what is wrong, but why, what the implications are, and how to fix it." Before hitting "send," double-check that every comment offers rationale and, when possible, a clear path forward.

Start improving your code review workflow today →

FAQ

Related Resources

• Best AI Code Review Tools 2025
• 12 Essential Code Refactoring Techniques
• AI Code Security: Risks & Best Practices
• Shift-Left Code Review: Pre-PR Tools
• Unit vs Integration Testing Guide