What Most Code Reviews Actually Catch
Most code review comments focus on conventions, variable names, styling, indentation, and missing unit tests. Simple and obvious mistakes are flagged too. Less frequently, reviewers comment on project and code structure, unhandled exceptions, basic optimizations, patterns, and best practices.
What Code Reviews Often Miss — And Why
But errors in algorithms and complex business logic are rarely highlighted during code reviews, along with performance bottlenecks and missed acceptance criteria. While these are difficult to catch, some can be spotted during code reviews, though they often require advanced approaches. Every issue found early significantly reduces the cost of fixing it and speeds up delivery.
So why do we usually miss these issues?
I think the main reasons are:
- CR tools display code differently from IDEs we’re used to. Fonts, colors, and backgrounds don’t match, so our brains don’t focus in the same way.
- Reviewers often read the code file-by-file in the order it appears in the CR. This can hide structure, context, dependencies, and execution order.
- Little time is allocated for CRs. Everyone is busy with their own tasks.
- Static code analysis, compilation warnings, and other advanced IDE features aren’t available in CR tools.
My Deep Review Workflow for Complex Changes
For small changes in familiar code, this isn’t a problem. But for brand-new apps, complex business logic, or deep refactoring, reading the code in a CR tool is not enough.
In those cases, I take the “hard way”:
- Read the user story and acceptance criteria.
- Review the code in the CR tool to understand the scope and spot complex areas.
- Open the branch in my IDE and build it. Compiler warnings and static analysis suggestions are good indicators of areas to improve. For some reason, many of them are ignored during development.
- Review from the entry point (for example, a Web API endpoint) or from updated business logic, following the runtime flow. Check the caller code too if it’s present.
- Sometimes, it’s useful to open the documentation or even the third-party library code to ensure correct usage (e.g., if the thrown exceptions are handled in our code).
- If I suspect input or edge case issues, I run the app and test it quickly, or even debug it.
- Use an AI agent to analyze the code. Here I’ve shared useful AI prompts for it.
- Check the code coverage.
This approach is complicated and time-consuming. It may take hours, but it’s usually worth it.
How I Write Review Comments
How I write comments matters too:
- I explain my reasoning and sometimes link to docs or articles.
- For repeating issues, I refer to the first comment or note that the fix applies in multiple places.
- If I’m unsure about the code’s purpose or correctness, I ask for clarification in my comment.
- I suggest authors mark comments as completed or reply to them as “done” rather than resolving them immediately, so I can double-check before approving the change.
Sometimes I have a short call with the author after the review.
And how do you approach complex code reviews? What do you focus on?