Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles
(untagged)

Code Reviews: Understanding and Breaking the Stigma

0.00/5 (No votes)
12 Dec 2012 1  
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
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 has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here