I'm getting through some unread posts in my aggregator today and came across this one on code reviews from Jeff Atwood.  Earlier this month I blogged some random thoughts on code reviews and Jeff's post just adds to their importance, even if its just a one-on-one review.     A guy named Diego left a comment that hit me:

“I've heard of (sometimes) reviews being done in groups. This seems very unproductive to have (maybe) a whole development team doing a code review. Say, for example, the coder presents their code and the dev. team looks through it. These are less common types of reviews?“

We currently do our code reviews this way.  I'll be honest, I think we do it this way just so everyone can get an insight into what people are thinking as a group.  Since we may not work with other team members on any projects we can tap into their knowledge and/or ideas.  I'm not real sure if we are getting anything out of our current setup except for that and maybe seeing other people's code.  Again, we normally do it after a project is complete which isn't the best time to do it either.

He recommended a book on code reviews, Peer Reviews in Software, that has two sample chapters you can download.  I plan on reading them and maybe acquire the book too.