How can we motivate students to review each other's code?
You have an opportunity for several things here:


You can make it a small-team effort rather than a whole-class thing. Say, a team of about 5. 
The team reviews everyone's code in sequence so all get to participate. Instead of a "code-review" it can be a "code-quality-workshop". 
The team has to write up the results of the review, with an addendum by the code's author about how the code was improved. (Writing is good.)
A whole-class retrospective on the process and its effect. (Retrospectives are good.)


If you have several groups working at once, you will need to wander around and participate in each group, giving pointers on process (rather than product). But you also need to do that if you have the whole class as the set of reviewers, of course. 



An alternative to code reviews, of course, is pair programming, where the need for reviews is lessened or eliminated. Two minds working together are stronger than than the two working separately it turns out when creating code. Code quality has been observed to improve and quantity (statistically speaking) doesn't go down by enough to overcome the quality issue. 



You may need to add a level of peer evaluation/review to this as well. Something like the following has worked for me over several years. In any group assignment, each member of the group also submits a peer review sheet. For a group of two (e.g. pair programming) I ask each participant to detail the most important contribution of their partner AND their own most important contribution. I don't ask who worked harder or ask them to make an evaluation. I ask them for the contributions. 

In a group of about five, I will ask each member to name the (say) three most important members of their group and to mention the key contribution of each. I tell them that they can include themself in the list of three. I also ask, separately for their own most important contribution. 

I let them know at the beginning of the course that this will happen and its parameters, so it isn't a surprise. 

Students see that they are supposed to contribute to a group and are not asked to speak ill of anyone. Keep the questions entirely positive. But you also learn a lot from what is not said and who is not included in the contributor list. 

If the project happens outside your view, you also learn things about individuals that you can not otherwise know. I've had students I thought were slacking who were praised by teammates for making the team work properly. 

These peer evaluations are not optional. 

This same idea was also discussed here: https://cseducators.stackexchange.com/a/2578/1293



Let me note that there may be cultural limitations here. In some cultures it may be odd to name oneself as a top contributor. In others it might be very natural. You can modify the scheme, of course, either requiring or forbidding naming oneself as one of the top people. Use your judgement here.