Have the Review
This is the most important step — far too much code sneaks through without any sort of review. If you know a code review is coming, I guarantee you will spend more time cleaning up your code.
Don’t be too Formal
One of the first projects I worked on many years ago had a formal code review process. We had specific forms to fill out, and huge lists of categories for things like “type of issue”. There were far too many choices, so nobody ever knew what to pick. In the end, having too many choices led to useless data. Plus, we all dreaded code reviews.
See it Run
I always ask the programmer to show the feature in action before we see the code, so we all understand what we are reviewing.
I try really hard to find ways to make the code fail. I’d rather find errors now than after deployment.
Avoid Duplication / Learn from Others
Without reviews, programmers work in relative isolation from each other. As a result:
- They don’t learn from their peers, because they may not be aware of other approaches to similar problems in the code base
- Code is duplicated, for the same reason
Having routine reviews is the best way I know of to ensure programmers really see and learn from each other’s code, and avoid writing the same thing over and over again.
If I can think of ways to simplify code, I’ll offer those suggestions in a code review. Try to imagine looking at this code a year from now without the original programmer present. Like it or not, each line of today’s code will become tomorrow’s legacy code.