Image for post
Image for post
Photo by Yancy Min on Unsplash

A Simple Checklist for a Good Code Review

Filipe Good
Jan 24 · 3 min read

Hi, I’m a recent Master graduate and despite having 2 years of work experience I only started doing serious code review for the last 7 months in my new job.

Being a Junior Software Developer I always struggled with code reviews because I was “afraid” of the Senior Developers. We never learn how to do a code review in school, so I searched on the internet to find guides and tips for a good review. I found many websites but none of them had a clear and simple checklist. This article tries to gather the information collected from multiple websites into a simple checklist that you can use when you are reviewing your peer’s code.

First, let me just write a bit about why I like doing code reviews (I believe that many developers don’t like it) and why I think they are important. When I started in my new job, I was overwhelmed with the technologies used in the project and the codebase of the project. It was my first time using several technologies and I had quite a big technical debt. On top of this, the project has a lot of peculiarities from the business side. The one thing that accelerated my understanding of the project was reviewing code! As I reviewed code, I could understand little bits of code (features) instead of trying to understand the whole project at once. This was a lot easier and, feature by feature (pull request by pull request), I got to understand better the project and the code itself. Because of that, I now love to review code! I now view every pull request that enters the codebase because I really want to understand all of the little pieces that, combined, make up the project.

Of course, there are a lot of other benefits of code review. But as the title suggests, this is a simple article so let’s keep it simple and straightforward :)

The checklist:

Does the code handle edge cases?

Do you see duplicated code? Can this code be abstracted?

Is there a way to make the code shorter/easier/faster/etc?

Is the code hard to understand? And what about the names, are they clear? Comments in the code are well thought?

All variables and methods are named correctly?

All new variables are declared?

Does the change add run-time or it has performance issues?

Are all parameters well defined and with the correct type?

Are the libraries well imported? Are we using deprecated methods?

Does the code follow the project standards and naming conventions?

The tone of my comments is positive and will not hurt the other developer feelings?

In my comments, do I avoid giving orders and instead give suggestions? (“Change this method to xxxx” vs “ What do you think about changing this method to xxxx?”)

Do I critique the code and not the author? (“Why did YOU….?” vs “What is the reason behind this….”)

I hope you find this helpful :) you can use this checklist whenever you review code. If you have other suggestions, please add them in a comment.

Let’s do better reviews, start to like them and in the end build great projects :)

The Startup

Medium's largest active publication, followed by +775K people. Follow to join our community.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store