Throughout my professional and my personal career I've been participated in, and been on the receiving end, of a lot of code reviews. I've compiled a few tips that have greatly improved my code reviews as well as improved the code reviews I've participated in.
As A Developer:
1. Post frequently and often
Nothing upsets reviewers more than when a big stinking code review pops up in their inbox - you know the one, with an absurdly large number of files changed each with an absurdly large number of lines changed. Don't do that. In general, as a developer, post your code in small increments to be reviewed. It makes it more digestible for your audience and helps you avoid coding down a wrong path or missing requirements that someone else might be aware of. In my experience, people are more likely to review smaller, more frequent, changes with greater precision and with a quicker turn-around on your review.
2. Changes should be self-explanatory
If you started a code review and immediately post comments explaining your coding decisions then you did it wrong - that's what code comments are for. Your changes should need no explanation since any ambiguous alterations should have a respective code comment in them, right? Right! As a developer, I don't want to go look up a code review 6 months later to figure out why something was done the way it was. It should be right there with the code!
3. Don't take it personal
Developers can be very defensive about their coding styles and reviewers can be eager to evangelize theirs. Everyone does things differently, don't let it ruin your day. It is, or should be, constructive criticism - there to make you a better developer. If you truly believe your way of doing something is better then calmly talk it out with the reviewer. You could actually be teaching them something! Never freak out over a code review.
As A Reviewer:
1. Review quickly!
Dedicate time to reviewing other's code. Don't let it pile up till the end of the week. In fact, if you can review it as soon as it hits your mailbox I'm sure the developer on the other end will be appreciative and return the favour when it's your turn to be under the magnifying glass. From a developers point of view, nothing slashes productivity better than waiting on others to review your code so you can press on. Personally, if my code review sits, untouched, for more than a day or two then I'm in people's faces about it - and that's uncomfortable for both of us.
2. You're not as great as you think - or maybe you are...
Everyone codes at a different level. Some code better than you, some worse. Temper your ego when you review. Nothing is more off-putting than a programming guru attempt to jam their "wisdom" down the throats of others. If you nit-pick about every little thing, or bash design decisions, then nobody is going to want you to review their work. Even worse, if your ivy-tower comments turn out to be wrong then you'll appear to others as an ego-driven developer who is also a fool.
3. Positive comments are welcome too
Code reviews are not just about picking out the flaws in other people's code. It should be a positive experience for both of you. Remember to be kind! When warranted, throw a "good job" or "nicely done" in there. It feels good to be on the receiving end of these types of comments. Even more so, code reviews should be learning expereiences for both of you, remember to let the person know when they've taught you something new or impressed you with a new technique that you were not aware of! Positive comments really go a long way.