There are many excellent points above by both kvale and dragonchild. Here is my two cents for what its worth.

There are a number of ways to go about code review, and I have participated in each kind and found they all have their benefits and drawbacks.

1. Group Code Review

   This tends to get really boring, really fast (as most meetings here in the corporate world do), especially if it is too detail oriented. However, I have seen a lot of value (given the right mix of people) when more high level elements of the code/implementation are discussed and debated in this format. Now discussing code at too high a level, I would guess, would not work in your world since it would basically be a discussion about your assignment. However, if you stick to how it is implemented, and not what is implemented it may work out. It could also be thought of as a post-assignment exercise if that helps.

2. One on One Code Review

   This is personally my favorite and have proven to me to be the most fruitful. The basic idea is you sit down with someone and explain your code to them while they ask probing questions about why you did this, and how you did that, etc. A lot of times, your best revelations come from the act of explaining your code too. I have also seen this work with more than one other person as well, although sometimes that degrades into too much side discussion.

3. Private Code Reveiws

   You give me your code, I go somewhere and review it. This is what you seem to be proposing above. This method can be really valuable, but tends to take a lot of time and many times requires the reviewer to really know their stuff. To be honest, I have only ever known a few people in my career (PerlMonks not included) whom I have felt doing this with was worthwhile.

As I said, I have seen all three of these approaches work, and all three of them fail miserably. The single most important element to success though, is an open mind and a willingness to take and give criticism (preferably constructive) on the part of all involved. Nothing will derail this process sooner, than a reviewee who can't take a little criticism or reviewers who are afraid to speak up.