Home » Software Development » Tips for Code Review Success

About Keyhole Software

Keyhole is a midwest-based consulting firm with a tight-knit technical team. We work primarily with Java, JavaScript and .NET technologies, specializing in application development. We love the challenge that comes in consulting and blog often regarding some of the technical situations and technologies we face.

Tips for Code Review Success

I’ve had the opportunity to be involved in various group peer code reviewing scenarios and sometimes I find myself wondering – is this worth it? (This is often followed by my drifting mind wondering if the cafeteria in whatever building has any more cookies, while a 20-minute-long off-topic conversation on the review sadly ensures that the cookies will be gone.)

Personally I think that yes, code reviews are often important to both help maintain a quality code base and, by doing so, also help limit production issues. Reviews aren’t always to find mistakes but also help find a better way (more reuse, more efficiency, more readability) to solve the issue, which improves the overall quality of the code. In addition to enhanced quality, an equally great goal of reviews is to help spread knowledge about the code base to the whole team.

Note: There are lots of arguments as to whether they are not needed in a pure Agile environment and I’m not really addressing that here. I’m assuming a team where some aspects of Agile may be used, but not for example pair programming, which limits the need greatly.

All of this is good, but code reviews can be costly in terms of developer time, so while in the right situations they can be great, it’s also important to keep them on task and limit the scope up front.

Here are some items to focus on to help make your code reviews effective:

Prep work should take place 

People should make a practice of already following the written coding standards for the team so that not too much time is taken up by worrying about things like project-specific naming conventions. It’s important that these are met and occasionally finding them in review makes sense, but can too much emphasis can pull everyone off task (there are not unlimited cookies people, seriously).

Focusing on things like formatting is also a sign that things are not on task. If there is a way to standardize something automatically in your IDE, then everyone should absolutely be doing that. It shouldn’t need to be mentioned in the review.

In addition, making it a practice to use static code analysis tools like FindBugs and code coverage tools like Cobertura to ensure test coverage will help find issues that may have been missed and help keep reviews short and focused. This leaves the reviewers to focus on more subtle logic and design issues, etc.

Keep it short and frequent

 Reviewing takes a great deal of concentration and longer periods can lead tiring and missing issues. Plus, it does take away from development time, so of course it’s helpful to stay quick and on task.

It’s best to have the changes fresh in everyone’s head. There are lots of ways to do reviews and what is best is going to vary by team and project, but whether you do over the shoulder, pair, send your code for review by tool or do a more formal review in a group, it is best to keep them frequent and small. Doing them more often means that major issues can be resolved before they have gone too far.

Everyone plays

 Even the most advanced architect or super star developer can make mistakes. It’s so much better to catch them here. Plus, again, it’s a learning opportunity for more junior people and people that are newer to the application.

Constructive Input

 General comments like “more comments” are generally, well, less than helpful. An interface with no comments might be an exception here, and documentation is good, but if you see something that doesn’t make sense this is the time to figure out why it’s confusing and determine if the design can be improved or if an error in the logic exists.

Focus on truly understanding what the code does and ensuring that if someone else needs to maintain it, they can understand it.


 Use tools designed for code reviews to speed and ease the process. For example, Crucible is the popular Atlassian code review tool which provides a lot of great reviewing features.


 There is probably no need to go overboard on these or to be too structured, but if certain issues keep cropping up, having a checklist can be a handy tool.

Positive Environment

 However many people are involved, make it a positive team effort to share information and create the best application possible.

Happy reviewing. Now, go get that cookie and get back to developing.

Reference: Tips for Code Review Success from our JCG partner Adrienne Gessler at the Keyhole Software blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design

and many more ....


Leave a Reply

Your email address will not be published. Required fields are marked *


Want to take your Java Skills to the next level?
Grab our programming books for FREE!
  • Save time by leveraging our field-tested solutions to common problems.
  • The books cover a wide range of topics, from JPA and JUnit, to JMeter and Android.
  • Each book comes as a standalone guide (with source code provided), so that you use it as reference.
Last Step ...

Where should we send the free eBooks?

Good Work!
To download the books, please verify your email address by following the instructions found on the email we just sent you.