Code reviews are important for maintaining high code quality standards, however, certain practices can hinder the effectiveness of these reviews and lead to frustration among team members. In this guide, we take a look into what not to do during code reviews, spotlighting common pitfalls and emphasizing how tools like Graphite's PR inbox can streamline the review process.
1. Not setting clear expectations
Before diving into reviews, it's important that all participants understand what is expected of them. Without clear guidelines, reviewers might focus on trivial aspects such as coding style rather than significant issues like code logic and architecture. Establishing a review checklist and expected standards can guide reviewers to focus on what truly matters. Here's a helpful checklist for you to keep in mind during your reviews.
2. Too much nitpicking
Focusing excessively on minor issues or personal preferences can detract from important discussions about the code’s functionality and design. This approach not only demoralizes the contributor but also delays the review process. Reviewers should prioritize comments that impact the overall quality and functionality of the code. Not sure what constitues a nit? Check out our guide on nits and why they're problematic.
3. Leaving vague comments
Vague feedback such as "This looks weird" or "I don’t like this" can be confusing and unhelpful. Comments should be constructive and provide clear, actionable suggestions. Instead of vague critiques, specify what exactly is problematic and why, and if possible, suggest a solutionn. Take a look at our guide on code review comments to learn more about how to avoid leaving vague comments.
4. Making the review personal
Code reviews are about the code, not the one who wrote the code. Comments that directly criticize the developer rather than the code can create a hostile environment and discourage future contributions. Always keep the feedback objective and focused on the code.
5. Conducting marathon review sessions
Long, drawn-out review sessions can lead to fatigue and decreased attention to detail, which increases the likelihood of missing critical issues. It’s more effective to keep code reviews short and frequent. If a PR is too large, it should be broken down into manageable pieces. Teams should also consider stacking their PRs. This approach helps keep each PR focused and small, making the review process quicker and more efficient, as reviewers can concentrate on specific features or improvements without being overwhelmed by a large volume of changes all at once.
6. Not utilizing automation
Automating mundane tasks can significantly speed up the code review process. Tools that enforce style guides, run tests, and check for common errors can free up human reviewers to focus on more complex issues. For instance, integrating linters can ensure that basic standards are met before human review begins.
7. Overlooking the PR inbox in Graphite
Graphite’s PR inbox functions like an email client for your pull requests (PRs), helping you stay organized and aware of PRs that require your attention. Neglecting to use such tools leads to missed notifications and a pile-up of unreviewed code. Teams should leverage the PR inbox to ensure that no PR goes unnoticed, especially those marked as "Needs your review" or "Waiting for review."
By avoiding these poor practices, teams can enhance the effectiveness of their code reviews. Remember, tools like Graphite's PR inbox and linters are designed to assist in these efforts, ensuring reviews are timely and productive.
