What Exactly Should You Look for When Reviewing Code?

Why code review matters

Many articles praise the benefits of code review, but few give concrete guidance on what reviewers should actually check. This guide outlines key areas to focus on, acknowledging that some checks can be automated while others require human insight.

What to look for when reviewing others' code

Formatting : spacing, line breaks, tabs vs spaces, brace placement.

Style : use of final, similarity between variable names and their usage.

Naming : consistency and clarity of domain, constant, variable, parameter, and class names.

Test coverage : whether the code is covered by automated tests.

Design considerations

Does the new code fit the overall architecture?

Does it follow SOLID principles, domain‑driven design, and team‑preferred patterns?

Are appropriate design patterns used?

Is the code consistent with existing style, especially in mixed‑standard codebases?

Is the code placed in the correct module or layer?

Can the code be reused, or does it introduce unnecessary duplication?

Does it respect YAGNI and avoid premature abstraction?

Readability and maintainability

Do names clearly reflect their purpose?

Can a reader understand the intent of the code and its tests?

Are exception messages understandable?

Are complex sections documented or covered by clear tests?

Functional correctness

Does the code behave as expected and meet its specifications?

Are there subtle bugs such as using the wrong logical operator?

Security and compliance

Are there potential security issues?

Does the code meet relevant standards or regulatory requirements?

Could the changes introduce performance regressions, especially in untested paths?

Are user‑facing messages accurate and safe?

Is there any hard‑coded test data or credentials?

Testing concerns

Reviewers should verify that new or modified code has appropriate tests, that critical paths are covered, and that tests express the intended behavior clearly. Automated coverage tools can highlight uncovered lines, but reviewers must assess whether the uncovered code is truly insignificant.

When coverage reports show red lines, reviewers should ask the author to add tests for those branches.

Performance considerations

Are there hard performance requirements or SLAs?

Are there automated performance tests to verify them?

Do new changes risk degrading existing performance metrics?

Are there unnecessary database or network calls, especially inside loops?

Is resource usage (CPU, memory, connections) reasonable?

Are locks or synchronization used appropriately, avoiding deadlocks?

Is there potential for memory leaks or unbounded growth?

Concurrency and correctness

Are thread‑safe data structures used where needed?

Could race conditions arise from non‑atomic get/set sequences?

Is lock usage correct, or could atomic variables replace locks?

Code‑level optimizations

Avoid unnecessary synchronization in single‑threaded contexts.

Prefer non‑blocking data structures over legacy ones like Vector.

Choose data structures with appropriate performance characteristics.

Replace locks with atomic variables when possible.

Consider lazy loading and short‑circuit evaluation.

Reduce expensive string formatting in logging unless the log level warrants it.

Overall, a thorough code review balances automated checks with human judgment, ensuring that code is clean, performant, secure, and well‑tested before it reaches production.