Get a 1-month FREE trial of Bito’s AI Code Review Agent  
Get a 1-month FREE trial
of Bito’s AI Code Review Agent

The Best Way to Do a Code Review on GitHub

The Best Way to Do a Code Review on GitHub

Table of Contents

Code reviews are an essential part of the software development process. By having a second set of eyes examine changes in code, teams can reduce bugs and improve code quality. GitHub’s built-in code review tools make it easy for developers to collaborate on a pull request before merging code into the main branch. This article will examine the best practices for performing effective code reviews using GitHub.

Code reviews allow developers to carefully go through proposed code changes line-by-line. They help find bugs, improve code readability and organization, and spread knowledge throughout the team. GitHub has useful features for commenting, approving/requesting changes, and managing pull requests under review. By following key best practices, reviewers can provide valuable feedback and ensure changes meet project standards.

The Benefits of Code Reviews

  • Find Bugs Early: Reviewing code changes before they are merged catches issues while they are small. Finding bugs at this stage is much easier than debugging after code is deployed.
  • Improve Code Quality: Reviewers can suggest better ways to structure code or optimize performance. A second set of eyes helps ensure coding best practices are followed.
  • Transfer Knowledge: Code reviews allow teammates to learn from each other’s work. Reviewers gain exposure to new techniques and code patterns.
  • Ensure Consistency: Reviews help a codebase follow consistent style and architecture. This makes the code easier to maintain over time.
  • Facilitate Collaboration: Developers get a chance to discuss implementations and provide feedback on each other’s work. This leads to better solutions and team relationships.

GitHub’s Code Review Tools

GitHub has built-in features that facilitate efficient code reviews:

  • Line Comments: Allow feedback on specific lines of code.
  • Single Unified View: All changes on a pull request are shown in one place for easy review.
  • Request Changes: Reviewers can indicate required modifications before merging.
  • Approve/Reject: Pull requests can be approved or rejected with a click.
  • Notifications: @mentions notify developers to review a pull request.

By using these tools effectively, reviewers can streamline the process and provide actionable feedback.

Starting a Code Review

To kick off a code review on GitHub:

Create a Branch for Each Feature or Fix

Changes should be implemented on a separate branch, not directly on main. This allows pull requests to target just the relevant commits.

git checkout -b new-feature

# Develop the feature

git add .

git commit -m “Add new feature”

git push origin new-feature

Open a Pull Request when Ready for Review

Once the branch contains the changes to review, open a pull request.

Add a descriptive title and summary explaining the purpose of the changes. Link to any related issues.

@Mention Reviewers to Request a Review

Use @mentions to notify teammates that a review is needed. This sends them an email notification.

@octocat @hubot Could you please review this PR?

Allow Time for Reviewers to Examine the Code

Understand that reviewers need sufficient time to thoroughly go through code changes. Avoid merging too quickly.

Reviewing Code Effectively

To provide useful feedback during a code review:

Focus on Code Quality, Not the Developer

Critique the code, not the person who wrote it. Provide objective analysis of how to improve the changes.

Provide Clear, Actionable Feedback

Use specific comments that explain issues and how to address them. This makes it easy for the developer to improve their code.

Check Code Functionality Yourself

Don’t just assume the code works. Reviewers should verify new features and bug fixes themselves before approving.

Limit Time Spent on Each Review

Long review times delay development. Try to review actively and limit time spent to 1-2 hours per pull request.

Providing Constructive Feedback

Giving thoughtful, considerate feedback improves code while maintaining positive team dynamics:

Be Kind But Firm in Assessing Code

Review objectively while being sensitive to how wording impacts others. Focus critiques on the code rather than the coder.

Suggest Specific Improvements

Don’t just say what’s wrong. Offer concrete recommendations to fix issues. Provide example code or links to relevant documentation.

// Consider extracting this logic into a separate function
// for better readability.
const getUser = userId => {
  // database lookup
}
// Could call the function like:
const user = getUser(userId);

Use GitHub’s Built-In Tools for Commenting

Take advantage of line comments and review tools. These features create useful conversation threads around feedback.

Avoid Nitpicking Small Details

Don’t waste time on trivial style choices or personal preferences. Focus reviews on catching significant bugs and architectural issues.

Handling Disagreements

Even experienced developers sometimes disagree during reviews. Handle conflicts professionally:

Discuss Any Major Disagreements in Real Time

Hop on a quick call to talk through differing opinions and find a resolution. Real-time chat conveys nuance better than written comments.

Don’t Let Egos Get in the Way of Good Code

Be open to learning from teammates. Consider that you may not always have the right answer.

Make Your Case and Be Open to Alternatives

Explain your viewpoint while also listening to others. Compromise if needed to reach the optimal solution.

Focus on What’s Best for the Project

At the end of the day, aim to merge well-tested, maintainable code that moves the project forward.

Automating Parts of the Process

Certain code quality checks and testing can be automated:

Use CI Tests to Catch Issues Early

Run unit and integration tests automatically with continuous integration like GitHub Actions. This provides feedback on pull requests before review.

# .github/workflows/ci.yml
on: pull_request
jobs:
  buildAndTest:
    runs-on: ubuntu-latest
    steps:    
    - uses: actions/checkout@v2
    - run: npm install
    - run: npm run build --if-present
    - run: npm test

Check Code Coverage to Ensure Testing

Use a code coverage tool to validate test quality on pull requests. Reviewers can then focus manual testing on uncovered areas.

Enforce Standards with PR Templates

Pull request templates remind developers to provide necessary info upfront.

# Description

Please include a summary of the change and which issue is fixed.

Fixes # (issue)

Type of change

Please delete options that are not relevant.

  • – [ ] Bug fix (non-breaking change which fixes an issue)
  • – [ ] New feature (non-breaking change which adds functionality)
  • – [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • – [ ] This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce.

  • Test A
  • Test B

Checklist

  • – [ ] My code follows the style guidelines of this project
  • – [ ] I have performed a self-review of my own code
  • – [ ] I have commented my code, particularly in hard-to-understand areas
  • – [ ] I have made corresponding changes to the documentation
  • – [ ] My changes generate no new warnings
  • – [ ] I have added tests that prove my fix is effective or that my feature works
  • – [ ] New and existing unit tests pass locally with my changes
  • – [ ] Any dependent changes have been merged and published in downstream modules

This template prompts developers to provide important context up front.

Conclusion

With some discipline, teams can use GitHub’s code review features to greatly improve their development practices. By being prompt, specific, and focused in giving feedback, reviewers help contributions get merged smoothly. Automation and project guidelines also assist in making reviews efficient and consistent. The result is cleaner code and more robust applications.

To recap, excellent code reviews involve:

  • Thoroughly inspecting changes line-by-line
  • Providing kind but constructive feedback
  • Testing functionality locally before approving
  • Resolving disagreements professionally
  • Automating repetitive checks where possible
  • Maintaining focus on what’s best for the codebase

By integrating code reviews into the development workflow, GitHub enables teams to collaborate on improving code quality. Following the best practices outlined here will help reviewers provide valuable feedback that moves projects forward. The investment of time during reviews pays enormous dividends in producing more maintainable and bug-free software.

Anand Das

Anand Das

Anand is Co-founder and CTO of Bito. He leads technical strategy and engineering, and is our biggest user! Formerly, Anand was CTO of Eyeota, a data company acquired by Dun & Bradstreet. He is co-founder of PubMatic, where he led the building of an ad exchange system that handles over 1 Trillion bids per day.

Amar Goel

Amar Goel

Amar is the Co-founder and CEO of Bito. With a background in software engineering and economics, Amar is a serial entrepreneur and has founded multiple companies including the publicly traded PubMatic and Komli Media.

From Bito team with

This article is brought to you by Bito – an AI developer assistant.

Latest posts

Bridging the Gap: AI Code Review vs Static Analysis Tools

Nitpicking in Code Reviews: Helpful or Harmful?

Are LLMs Commoditizing?

Major upgrades to the AI Code Review Agent and IDE extensions

The Hidden Cost of Code Review: Navigating Emotional Landscapes

Top posts

Bridging the Gap: AI Code Review vs Static Analysis Tools

Nitpicking in Code Reviews: Helpful or Harmful?

Are LLMs Commoditizing?

Major upgrades to the AI Code Review Agent and IDE extensions

The Hidden Cost of Code Review: Navigating Emotional Landscapes

From the blog

The latest industry news, interviews, technologies, and resources.

Get Bito for IDE of your choice