Recently the topic of code reviews has been coming up around me. I had been doing some consulting work last month. (Remember that game you played in school on graph paper? Go buy Family Dots, a family friendly game!) They mentioned that they had Jason Cohen conduct their technology related interviews because, “Hey, he created Code Collaborator. He programmed a program to help programmers. He’s a fan of code reviews. He must be a smart guy, right?”

Also quite recently, my friend began writing Objective-C. He’s not a bad programmer, but he is new to the nuances of the world of Obj-C. In fact, he’s much less of a bad developer in my mind because he was cautious. He asked me to help him out and give his source a quick code review.

In another, unrelated case, someone at work asked me to swing by for a code review of about ten or twenty files that would be going live and possibly seeing heavy use. It took us about twenty-five or thirty minutes, but we sifted through each and every change in that diff.

It seems code reviews have been popping up left and right for me and you know what? I am glad! You can doubt the power of a code review. You could argue that it costs more time than it saves. You would also be wrong! That’s right, I’ll go ahead and say it. Code reviews are an amazing way to catch potential bugs before they are born. It doesn’t have to be fancy, necessarily. The simplest of methods is better than the most absent of methods. It doesn’t have to feel like a firing squad, either. In fact, it shouldn’t. A code review should feel like your parents helping to nurse a newborn baby or helpful critique from your girlfriends before girls night out.

Listen, you’re prone to typos. No finger is too precise. A code review can catch that. You might make a small mistake in your order of operations. A code review can catch that. You might even be the root cause of some latent bugs! You know what? A code review can catch that. Just about any mistake has the potential to be caught in a code review. The owner of a system will tell you how radically different you’re using his interface than intended.

You ever hear people mention something about a second pair of eyes? (How about a third or fourth?) Attached to those eyes is a fresh, critical brain that thinks in an entirely different way. A whole new thought process! That unique brain has serious potential to find those killer logic bugs, or at least nitpick your variables until you find them yourself! Maybe you did not know that comparing to a string’s Length property was faster than a string comparison to String.Empty, or maybe you would rather be explicit and check String.IsNullOrEmpty(). (Maybe you didn’t know these lovely functions exist!) Hopefully, in a few weeks, months, or years your code won’t be that war zone other developers avoid.

So what am I saying here? Perform code reviews? Is that really my only piece of advice? Yup. (For now.) If I can sell you on the merits of doing peer code reviews now, maybe later I can talk about them in more depth. (Definitely expect a part two.) I believe they save more time than they cost. I think they help maintain solid, consistent, and readable code. Hopefully, programmers can better develop their skills through peer review as well. However, let me talk about those two code reviews I mentioned earlier a little bit.

My friend, new to Objective-C asked me to code review some of his work. Luckily for him, it turns out that I happen to know a little more about memory management in Objective-C than he does. There were a lot of small leaks that got cleaned up as a result and a whole pantload (That’s big.) of C++ code that translated into two or three Obj-C messages. It was like building a skyscraper when all you really needed was a doghouse.

At work, a new member of the team asked me to attend a code review since he would be checking code into a branch critical to me. (Read, a branch in which I deal with all the fallout.) During our review I found three critical issues that would have plagued my team much farther down the road. They were mostly catching unnamed exceptions. (Please don’t sweep exceptions under the rug, especially without naming them for your friendly neighbor, who will be debugging that code later.) This is exactly a problem we had seen in the code three or four times before and you know when your office mate hits it from the loud, “Ugh!” that suddenly fills the room.

So you see, much pain was saved in the long term by spending the time in the short on the code review. Whether you’re doing them over-the-shoulder, by email, by changelist, or by something Smarter like Code Collaborator, the code review is a powerful tool. I hope, if you did not believe in it already, I have sold you on the benefits of the code review.

  • Share/Bookmark