5 Tips To Create Better Pull Requests

Small suggestions to make the life of your reviewer easier

Photo by Markus Winkler on Unsplash.

Creating a PR and waiting for a code review is a standard approach to writing code. PRs and code reviews are very important in every developer’s day. They achieve different goals:

1. Share knowledge about the code base.
2. Mentor developers in order for them to become better.
3. Keep a high-quality standard.

The process is usually split into two steps: A developer prepares a PR and another developer (or several) performs a code review, pointing out the good parts and the parts that can be improved.

Today, I’d like to go through the first step, highlighting how we can create a PR that is easy to review for our colleagues. The easier we make their life, the more useful the review will be. It will also improve their opinion of us as a professional, and that is a nice perk!

1. Write an Informative Title

The very first idea we always have to keep in mind is that we know the context, while our reviewers don’t.

Starting with an informative title will immediately set the expectation of what the reviewer has to check and it gives them basic context.

For example, a PR called “BUGFIX” would tell the reviewer that they are about to check whether a bug has been fixed. But where? What bug is it?

A better title is something like “[FIX] Update product list when new products arrive from background.” This title immediately tells the reviewer several things:

1. It is a bugfix (as opposed to a feature implementation, some tests, or anything else).
2. It is related to the product list of the app.
3. It explains when the bug was happening.
4. It explains what the desired outcome is.

Pro tip: Depending on your company culture, team manifesto, or any convention, sometimes is useful to add emoji at the beginning of the title. For example, we often use the 🐛 emoji for bug fixing or the 📚 emoji for the docs. It gives a visual clue of what is going on.

2. Don’t Forget the…