5 Tips for better code reviews

A big part of software engineering is code review. Good code reviews will help your code base become better and help you and your colleagues learn from each other. Let’s take a look at some code review best practices and tips!

1: Have your tools check the code for you

The best way to have good code review is to reduce what needs to be reviewed as much as possible. When reviewing code, I shouldn’t have to check whether you’re indenting with tabs or spaces, a tool should do that. I shouldn’t have to check if the tests pass, that should be done in CI.

This doesn’t mean we need a passing CI before we can do code review. Sometimes we know there is an error happening, but we are looking for some early input to see if we are heading in the right direction.

2: Ask questions instead of demanding changes

This is especially important when dealing with junior developers, who might not be as confident about their code as more senior developers. For example, if an input field could be of type email you should not just say Hey, this can be type="email". Instead, ask the other developer why they chose for type text. It might be that legacy users don’t have email addresses, but usernames. Or you might be right and it could be of type email, in which case they can change it. But if you just demand a change to be made, the dev might just think you know better and change it without pushing back.

3: All devs should code review

Some folks think that only seniors should do the code review, but I always encourage junior developers to do code review as well. It’s a great way to learn about the codebase, and about the decisions someone made while coding. It does mean that seniors will have to spend a bit of extra time to answer the question that may pop up during the review, but it will increase the skills of the juniors on your team a lot.

4: Review things that matter

As developers, we sometimes get stuck on small unimportant things, and we can spend three days arguing whether a variable should be called $password or $userPassword. Try to avoid these kinds of things while doing code review. Instead, focus on the bigger things in a code review, look at bottlenecks that may cause performance issues, and make sure the code will be readable by the next person to look at it.

5: Use FTI or NIT

If something is more of an off-hand comment, or doesn’t need to be changed, you can use FTI: or NIT: in front of your comment, which stand for Free To Ignore and Nitpick respectively. You can use this for comments that don’t matter that much, and you could see as nice to haves. Maybe someone is refactoring a legacy class, but didn’t add types everywhere. This isn’t a dealbreaker since we are already doing some boy scouting, but more improvements could be made.

In that case you could leave a comment like: “FTI: There are still some types missing on the methods, maybe we can add those as well?” Because of the FTI:, the developer knows they don’t have to do this. Generally speaking no changes need to be made, if you have a reason why the current solution is better than what the reviewer is asking. But with FTI:, you give the developer permission to ignore it, or just not make the change without having to reply.

If you want to get notified of the next blog post, join the newsletter.