Code Review Boredom
I remember taking a class where we had to perform a “code review”. The idea of a code review was that you periodically organize a meeting “not to last longer than three hours” and go line by line, asking questions and verify your thoughts as a developer. So one day we spent a class period and “reviewed” code.
It was a total waste of time, I could have been playing Unreal Tournament.
Email Has Its Use
First, why sit around a table and watch someone read your code? Most of the time the person reading your code will actually understand it! It isn’t like it’s written in hieroglyphics and he needs you there to translate it for him (and if he does need translation, maybe you should review your coding style).
Use email. One, people can paste lines of code they have questions about and ask directly “What does this line do?” instead of pointing at a piece of paper or reading line numbers.
Second, it allows you, the developer, to continue working on something else why the review is taking place.
And third, it doesn’t require everyone to have the same piece of time to be free.
Diff Is Awesome
So how often is it that you are checking in new files of completely new code? Not often.
Most of the time, you are checking in new code mixed in with old code. This is where a diff utility comes in real handy.
int MyClass::Perform( int element ) const
{
if( element < 0 )
return 0;
if( element >= THRESHOLD )
return element;
else
{
int row = m_row[element];
int total = row * 2;
return ( element + total );
}
return 0;
}
So I added a new check at the top of this function and removed an extraneous return at the end. If I was sitting in a code review, we could spend all day reviewing the logic in the function when in reality that piece of code could have been there for 20 years and all I did was add extra protection.
Even more importantly: You can see what I removed. I’ve seen many bugs introduced because someone removed one more extra line than they should have.
When Life Gives You Lemonade
Drink it. Because it tastes good. And it will freshen up any code review that takes you longer than three hours.
If your development process has something taking anywhere near 3 hours, please reconsider the pain you are causing people. Developers like to be at their computers, doing stuff. Not in meetings, fulfilling some arbitrary “code review meeting” requirement.
If you still have time to schedule code review meetings, then you’re not doing enough code reviews.
