Telerik blogs

Learn practical tips you can take to review pull requests effectively to ensure code quality, promote collaboration and maintain a healthy development process within a team.

Pull Requests (PRs) are a crucial aspect of the modern development workflow and are a mechanism for submitting code changes to a shared repository. In a previous article, we discussed simple steps one can take to create great pull requests, particularly when working with large teams with multiple developers.

In today’s article, we’ll discuss practical tips you can take to be a good pull request reviewer. Reviewing pull requests effectively helps ensure code quality, promotes collaboration and maintains a healthy development process within a team.

Understand the Pull Request

A pull request serves as a formal submission of code changes for review. When one begins the review process of a pull request, it’s important to first briefly understand the purpose of the pull request and what the code changes entail. Is your colleague/teammate creating a new feature, making a bug fix, improving code cleanliness or making some other form of code change?

Pull request description screen includes what, why, how, testing steps

This context can often be gained by reading through the pull request documentation and gaining a high-level understanding of the code’s intended outcome. Once this context is understood, the following steps listed in the article can help guide the rest of your review process.

Walk Through the Code Changes

Once the goal of the pull request is understood, the next suitable step in the review process is to walk through the code changes.

It can be helpful to first review the code changes on a high level before narrowing down to the specific line changes/additions/deletions that are being made. This entails first understanding what part of the codebase is being changed; which files are being added, modified, deleted; and what pattern of changes the developer is making.

Looking into the details of the proposed code changes

Once the proposed code changes are understood, you can then move to examining how the developer has implemented the code changes while paying attention to items like code organization and adherence to coding standards and team guidelines. This includes looking for things like code clarity, modularity and consistency in naming conventions.

Run the Code Locally

To fully comprehend the code’s behavior, sometimes it can be helpful to pull down the pull request branch and run the proposed code changes locally. When code changes are being run locally, we can utilize debuggers, step through the changes and observe the effects caused by the new code in more hands-on approach.

Running the code locally can enable a deeper understanding of the code and help us identify any potential issues that are more difficult to catch by simply reading the code changes.

Provide Feedback

Feedback can be placed on a pull request by providing comments on the entire pull request or specific code line changes.

Comment: I believe we can use an pimport alis/shortcut in the imports we make from files and directories within the /src/ directory. This will look like...

Pull request comments can often be categorized into the following:

  • Kudos – Comments that acknowledge and appreciate the developer’s work by highlighting the areas where they have excelled and/or done well. Recognizing a colleague’s effort not only boosts morale but also reinforces positive practices and encourages the teammate to continue their good work. It also leaves a paper trail that the colleague can use during performance reviews within their team and organization.

  • Questions – Comments to gather more context and understanding where needed. This helps both the reviewer and the developer clarify any uncertainties and promotes a constructive dialogue, leading to improved code quality.

  • Nitpicks – Comments that note minor issues that do not hinder the pull request from being merged but serve as reminders for future improvements.

When suggesting modifications, ensure that comments clearly describe the issue and include specific suggestions for improvement. It’s helpful to be descriptive when providing suggestions, by providing code snippets and pseudo-code where applicable since actionable suggestions makes it easier for the developer to make the necessary changes.

Be Positive and Empathetic

Throughout the review process, it is important to always approach the code review with positivity and empathy. Remember that constructive feedback and collaboration are key to helping foster a positive environment that encourages growth and improvement.

Recognize that your teammates and colleagues invest time and effort into their code, and feedback should be delivered respectfully by focusing on the code and never the individual. By fostering empathy and maintaining a supportive atmosphere, you can help promote a healthy code review culture within the team.


Conducting effective pull request reviews plays a vital role in maintaining code quality and promoting collaboration within a development team. By understanding the pull request, walking through the code changes, testing locally where applicable, providing feedback and emphasizing empathy—you can ensure an effective review process for pull request changes, promote continuous improvement and contribute to the overall success of the project.

About the Author

Hassan Djirdeh

Hassan is currently a senior frontend engineer at Doordash. Prior to Doordash, Hassan worked at Instacart and Shopify, where he helped build large production applications at-scale. Hassan is also a published author and course instructor and has helped thousands of students learn in-depth fronted engineering tools like React, Vue, TypeScript and GraphQL. Hassan’s non-work interests range widely and, when not in front of a computer screen, you can find him at the gym, going for walks or running through the six.

Related Posts


Comments are disabled in preview mode.