Mastering Code Reviews

I’m now a year into my software engineering career, and I’ve been looking for ways to challenge myself and make a bigger impact on my team. One way I’ve been doing this? Code reviews.

What Are Code Reviews?

Imagine we have a main repository—the home base for all our code. Before any new code is added, it needs to go through a quality check to make sure it’s solid. That’s where code reviews come in. Code reviews are like a safety net, ensuring everything is good to go before it’s merged into the main codebase.

When I was just starting out, I felt like I wasn’t “worthy” enough to do code reviews. I worried I didn’t know enough to catch errors or make useful suggestions. But here’s the truth: that’s just imposter syndrome talking.

One of the main goals of a code review is to make sure the code is readable. And as a junior developer, if you don’t understand a piece of code, that’s a clear sign it could be made clearer. So if you find yourself getting confused, that’s your opportunity to make a valuable contribution.

My Journey with Code Reviews

Now that I’ve set an intention to be more involved in code reviews, I’ve done some research on what makes a great code review, and I’ve reflected on my own past experiences. Here are some dos and don’ts I’ve picked up along the way:

Do’s and Don’ts of Code Reviews

1. DO take time to understand the context.

Before diving into the code, get familiar with the purpose. Check out any related tickets, documentation, or user stories. Understanding why the code was written helps you give better feedback.

Example: If the ticket specifies optimizing a search function, you can evaluate if the new code meets that goal. If it’s not clear, that’s a great point to raise.

2. DO focus on readability.

The code should be clear enough that someone with less experience—like a junior developer—can understand it. If something doesn’t make sense to you, suggest ways to improve clarity.

Example: If you see complex variable names or nested logic that’s hard to follow, you could suggest, “Could we rename this variable to be more descriptive?” or “Can we break this down into smaller functions for better readability?”

3. DON’T nitpick minor style issues.

It’s tempting to point out every small inconsistency, but avoid getting too caught up in things that don’t impact functionality or clarity. Stick to the bigger picture unless there’s a coding standard that needs to be enforced.

Example of a nitpick: Commenting on single vs. double quotes if it’s not standardized across the codebase. Focus on things that will genuinely improve the code’s quality.

4. DO look out for potential bugs.

Bugs can be hidden in the details. Test edge cases in your mind or run the code to see if it handles unexpected scenarios gracefully.

Example: If there’s a conditional statement, consider what happens if the data is null or if the input is outside the expected range. Ask questions like, “What happens if this value is negative?”

5. DO review the tests.

Tests are just as important as the code. See if the tests are thorough enough and whether edge cases are being handled. Suggest improvements if necessary.

Example: “I see we have tests for the happy path. Should we add some to handle edge cases like empty arrays or null inputs?”

6. DO be constructive and empowering.

Frame your feedback as questions or suggestions instead of commands. This opens up a dialogue and encourages collaboration.

Example: Instead of saying, “This is wrong,” try, “I’m curious why you chose this approach—could we achieve the same result with a different method?” This shows you’re seeking to understand, not criticize.

7. DON’T belittle or be harsh.

Avoid making comments that come off as judgmental or dismissive. Code reviews should be about helping each other, not tearing someone down.

Example to avoid: “This is a mess. It’s completely unreadable.” Instead, say, “I found this section a bit hard to follow—could we refactor it to make it clearer?”

8. DO explain your suggestions.

Don’t just point out what you’d like changed—explain why it’s better. This helps everyone learn and understand the reasoning behind the suggestion.

Example: “I recommend using a Set here instead of an Array because it will prevent duplicate values and improve lookup times.”

9. DO highlight the positives.

It’s easy to focus only on what needs improvement, but don’t forget to acknowledge what was done well. Positive feedback is just as important.

Example: “I really like how you’ve optimized this loop—it’s much more efficient and reduces memory usage!”

10. DO leave room for conversation.

Not everything has to be a firm suggestion. Sometimes it’s about opening up a dialogue. Encourage a follow-up discussion if needed.

Example: “This solution works, but I wonder if there’s a way to simplify it. What do you think about discussing this approach further?”

Extra Tips for Better Code Reviews

Read the Coding Standards

Every team or company usually has its own coding standards. Familiarize yourself with them and use them to guide your reviews. This way, if you suggest a change, you can refer back to those standards to support your reasoning.

Check Out ‘Clean Code’

A great book by Robert C. Martin, "Clean Code," is a go-to resource for understanding general good coding practices. It’s an excellent way to develop an eye for what makes code clean, efficient, and easy to maintain. It’ll help you assess if good practices have been applied.

Keep Practicing and Coding

The best way to get better at code reviews is to keep coding. The more you work in your programming language, the more familiar you become with best practices, common patterns, and efficient solutions. Experience will sharpen your instincts and help you spot potential improvements faster.

I’m always looking to get better at code reviews, so if you have any tips or best practices, I’d love to hear them!

Until next time,

Ruth