I started writing this as a comment to this piece from Keith Pitty I got carried away.
An even lighter weight approach that I like is having people subscribe to a mailing list of all the CVS commits that take place along with a diff of the changes. You can quickly see if an important file has been changed from the subject line, then you can inspect the changes in the email, and if you need more context you can go and view the whole file in CVS. If you find any problems you can reply to the author and even the whole list if you find something that needs attention.
So now a review has taken place and feedback given sometimes minutes after the code has been written. A middle ground between meeting based code reviews and pair programming maybe?
If meeting based reviews are required then I much prefer a presentation based review where the author/s walk through their code using their development environment and a projector. It is then much easier to browse the code and it's flow while also providing the opportunity to demonstrate it's actual purpose by running it! Crazy I know! Step away from the paper based reviews.
Focus on reviewing how the code satifies the requirements, how it fits within the overall design and try to identify any opportunities to refactor the code based on your knowledge of existing code.
Do NOT review code structure. Leave this up to products such as Checkstyle that will do a much better job. This may seem obvious but I have been in reviews where brace position and white space have been debated. That must have been the closest I have been to storming out of a meeting. Instead I stayed and was terribily hostile and unproductive. Some of you might have been in there with me. Lest we forget :)
Posted by dbradby at June 17, 2004 02:31 AM"Instead I stayed and was terribily hostile and unproductive."
We hang around too much :)
Posted by: Kris at June 20, 2004 09:56 AM