The Pragmatic Craftsman :: Simplicity from complexity : by Stanley Kubasek ::

I hesitated posting this… The last thing I want is more red tape. However, after reading about code reviews in several sources, I am convinced that the reward is worth the price. The bottom line, code reviews improve code quality. While no silver bullet, they force us to write better code — knowing that somebody else will evaluate it makes us do it.

I have never been part of a company where code reviews worked effectively, but at the same time, if implemented properly into the development process, they have the potential to improve the quality code in a significant way.

What’s more, they enable cross-training programmers, mentoring, and enforcement of code conventions. Code reviews allow us to make sure that new people are “adopting” to “our” way of doing things, if there are any. They’re the extra guard to protect the most-valued property: code.

A lot of the prominent IT gurus, like Grady Booch, Jerry Weinberg, Cedric Otaku (those are sitting on top of my mind now), are big proponents of code reivews. I believe Weigers even wrote a book on the subject.

What prompted me to write this is an excellent blog entry by Cedric Beaust, Why Code Reviews Are Good For You, http://beust.com/weblog/archives/000393.html. He explains why it’s good and the different types of reviews. The following sums it up nicely:

“I strongly believe that projects that work without any peer review will end up with code of significantly worse quality, regardless of how talented or experienced the developers are. It doesn’t matter how good you are, you can’t produce top quality code all the time. We all get sloppy at time, and code reviews are here to address these times.”

I think we should consider implementing non-blocking code reviews. Let’s be honest, we all check in code that is sometimes sloppy, we could all use a little incentive to do better, and a lot of times we write code that only we can understand. Code reviews would be an improvement in this area.

How do we implement it? Good question. I believe that there should be some communication system in place. But the bottom line, each line of code should be looked at by somebody else and suggestions how to make it better should be requested of each reviewer (no heart feelings).

At my current job we have JIRA and SVN integrated, doing code reviews would be simple. Every SVN check in has to have a ticket ID. Before a ticket can be closed and the project released, every change has to be reviewed by somebody else and commented on. Before it can be closed, the reviewer would have to approve that the changes have actually been implemented.

We all strive to write good quality code whether we do code reviews or not, but it does not always happen. Knowing that our code would be reviewed would force us to do it every time.

ReferenceWhy Code Reviews Are Good For You, Cedric Otaku

RelatedCode Reviews, very good java.net article