A detailed guide on what to focus on as a reviewer during pull requests.

Franco Fernando is a software engineer and technology enthusiast known for his expertise in web development and mobile applications. Readers can learn about coding best practices, software architecture patterns, and emerging technologies. With articles, tutorials, and code samples, Franco Fernando shares  insights and expertise for building modern and scalable software solutions.

The Polymathic Engineer

A comprehensive guide covering the essential aspects of effective code reviews, prioritized by importance. Covers design considerations as the most critical factor, followed by functionality review, complexity assessment, test quality evaluation, naming and documentation standards, and style consistency. Emphasizes the importance of structured approaches over random scanning, focusing on catching bugs, improving code quality, and facilitating team learning through systematic review practices.

What to Look for in Code Reviews

Sadly there is a limited time budget for proper code reviews, or the expectation is that this work is on top of your regular work. As for the article:
lgtm 👍🏼

I’m rather reluctant when it comes to code reviews. We’ve all experienced — or will eventually experience — that one developer who does a review but actually adds a lot of bad practices, simply because they’re convinced of the opposite.
Not long ago, I had a case with a developer who was very skilled in algorithmics, yet insisted vehemently that we should use assert statements in production (this was on a PHP framework).
No. asserts are meant for testing environments. But in the end, I stopped arguing — he was the lead. I’m not here to fight; I’m here for us to grow, myself included.
And that’s really my point: the idea of code reviews is often misunderstood and misapplied. It’s not about enforcing a dogma, a standard, or a single way of coding. It’s about growth. That means both parties involved in the review have to put in the work, bringing demonstrations and evidence, and above all, showing a great deal of introspection and humility — accepting that just because someone is less experienced doesn’t mean they’re wrong. It should be a dialogue where both sides come out having learned something: one by confirming and proving their point, and the other by having seen a proper demonstration.
And it’s much more complex than it seems. Take my assert case as an example: one could have simply said, “here’s the proof, this shows the assertion doesn’t fail,” and the other could have just accepted that. But if the review had been done properly, one would have played the thesis — showing why assert worked — and the other the antithesis, demonstrating that using assert in production is considered a vulnerability, because asserts are usually ignored in production, and that this violates SOLID principles, and so on.
That way, both would have grown from the exchange.

Reviewing test quality would typically be my first go to. If the tests don’t clearly show behavior and intention then the code isn’t ready. This in turn also tells you, if the tests are good, give you some indication that the code is probably functional and you can move on with the review.
Things like code style, if the tests actually work, formatting, etc should all be build steps and never even thought about by a reviewer because if they aren’t standard the build fails.
My typical advice is to focus on how quickly you understand the code. If you cannot understand what it’s doing quickly in a low pressure environment of a PR you’re really going to hate it in a high pressure production is down situation. The rest just falls into place.