Click here to Skip to main content
Click here to Skip to main content
Technical Blog

Tagged as

Code Reviews: Understanding and Breaking the Stigma

, 12 Dec 2012 CPOL
Rate this:
Please Sign up or sign in to vote.
The phrase "code review" can evoke a negative or emotional response from many programmers. The negative undertone stems from the perceived judgment of their work. It transports them back to the grade school stress before a final exam. Why is this? Like other professions during the industrial age, pr

Editorial Note

This article appears in the Third Party Product Reviews section. Articles in this section are for the members only and must not be used by tool vendors to promote or advertise products in any way, shape or form. Please report any spam or advertising.

The phrase "code review" can evoke a negative or emotional response from many programmers. The negative undertone stems from the perceived judgment of their work. It transports them back to the grade school stress before a final exam. Why is this? Like other professions during the industrial age, programmers build software with their hands and minds. Although it may look structured, programming is an art form. No two individuals have the same style, but they are proud and take ownership of their work. Passion is a large driving force in software development. Most individuals are concerned about how their work will be judged.

To properly implement code reviews and alleviate concerns, teams must educate themselves on its benefits and purpose. The following section outlines what code reviews aren't and what they are.

Code Reviews Aren't:
  • They are not a grading and ranking system for developers.
  • They do not have any bearing on performance reviews.
  • They are not an opportunity to change someone's coding style.
  • They are not a time for criticism or negative comments.
Code Reviews Are:
  • They help spread team knowledge about features.
  • They help identify possible logic or business gaps.
  • They are an excellent way to learn new tips and tricks for both parties.
  • They are a time for constructive feedback.

Code reviews should be a team activity with all members participating. Enabling each member to be a reviewer encourages trust, constructive conversation, and increases socialization. Don't forget, the learning process can go both ways. The reviewer may pick up a few coding tips as well. Performing a review should be very informal. When coding is complete (or possibly before), a team member should request a review from another member. Do not rush through the review. Show the same respect one would show to his/her own code. The purpose of the review is to understand the problem and how it was solved. It is not a witch hunt to find an issue. If everything looks good, a simple "looks great" will suffice. It does not need to be more complicated than that.

The results of performing code reviews are quite clear. Over time it elevates the code of the entire team. It also acts as an excellent mentoring tool for new or junior developers and provides invaluable one-on-one time with experienced team members. Even with these benefits, some still cringe at the words "code review." In an attempt to remove this stigma, some in the developer community have changed the phrase to "peer review." This is a positive change as it reinforces the team benefits and shifts the focus towards responsible team coding.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Zac Gery

United States United States
Software Developer, Mentor, Architect and UX/UI craftsman. Also, a psychology nut that loves curling.
Follow on   Twitter   Google+

Comments and Discussions

 
-- There are no messages in this forum --
| Advertise | Privacy | Terms of Use | Mobile
Web01 | 2.8.1411023.1 | Last Updated 12 Dec 2012
Article Copyright 2012 by Zac Gery
Everything else Copyright © CodeProject, 1999-2014
Layout: fixed | fluid