There are a few things that code reviews can do for you, and some things they can't. The arguments in favor of code reviews:
- Collective ownership
- Find bugs (QC)
- Enforce consistent style (QA)
- Mentoring
Many agile processes tackle those in different ways:
- Collective Ownership: everyone on the team is responsible for the project, which means everyone's eyes will be on the code at any given time.
- Free to refactor: this takes code reviews to the next level, and allows anyone on the team to perform refactoring as necessary.
- Unit tests (QC): unit tests are more efficient and less prone to human error then visual inspection. In fact, I have yet to find a more efficient means.
- Pair programming (QA): takes care of mentoring and provides early refactoring advice as the code is written. This is also still a controversial topic, but I find it helps while ramping up a new developer. It's also a good time to enforce coding standards.
In essence there are other avenues of taking care of the potential gains you would normally have doing peer reviews. My personal experience with peer reviews is that they are very inefficient mechanisms and are not effective at finding bugs or larger design flaws. However, they do have their place in some teams, and on projects where agile is not feasible (for whatever reason), they are quite necessary.
Types of reviews
There is no one true way to do peer reviews. There are many ways in which to judge whether code is of a sufficiently high quality. Clearly there is the question of whether it's buggy, or whether it has solutions that don't scale or which are brittle. Issues of conformance to local standards and guidelines, while perhaps not as critical as some of the others, is also part of what contributes to high quality code.
Types of reviewers
Just as we have different criteria for judging software, the people doing the judging are also different. We all have our own skills and predilections. Some may think that adhering to local standards is highly important, just as others might be more concerned with memory usage, or code coverage of your tests, and so on. You want all of these types of reviews, because as a whole they will help you write better code.
A peer review is collaboration, not a game of tag
I'm not sure you have the right to tell them how to do their job. Unless you know otherwise with certainty, assume that this person is trying to contribute the way he or she sees fit. However, if you see room for improvement, or suspect maybe they don't understand what is expected in a peer review, talk to them.
The point of a peer review is to involve your peers. Involvement isn't throwing code over a wall and waiting for a response to be thrown back. Involvement is working together to make better code. Engage in a conversation with them.
Advice
Towards the end of your question you wrote:
how would I go about encouraging colleagues to actually look for
faults in the code in balance with glaring aesthetic errors?
Again, the answer is communication. Perhaps you can ask them "hey, I appreciate you catching these mistakes. It would help me tremendously if you could also focus on some deeper issues such as whether I'm structuring my code properly. I know it takes time, but it would really help."
On a more pragmatic note, I personally divide code review comments into two camps and phrase them appropriately: things that must be fixed, and things that are more cosmetic. I would never prevent solid, working code from being checked in if there were too many blank lines at the end of a file. I will point it out, however, but I'll do so with something like "our guidelines say to have a single blank line at the end, and you have 20. It's not a show-stopper, but if you get a chance you might want to fix it".
Here's something else to consider: it may be a pet peeve of yours that they do such a shallow review of your code. It may very well be that a pet peeve of theirs is that you (or some other teammate who gets a similar review) are sloppy with respect to your own organization's coding standards, and this is how they have chosen to communicate that with you.
What to do after the review
And lastly, a bit of advice after the review: When committing code after a review, you might want to consider taking care of all the cosmetic things in one commit, and the functional changes in another. Mixing the two can make it hard to differentiate significant changes from insignificant ones. Make all of the cosmetic changes and then commit with a message like "cosmetic; no functional changes".
Best Answer
At my work we have the following procedure for code reviews. It has worked well for us so far, and we found it to be very time-efficient, especially in terms of man-hours. We do not really have any specific time allocated to the reviews. Every commit or merge to the trunk must be reviewed, and it takes as long as it takes for the reviewer to ok it.
Edit: The time it takes, of course, depends on the magnitude of the change. Small features and bug fixes take minutes. Large new features, refactorings, or changes that affect many parts of the system can take half a day to review and another day to address all the issues that come up as a result.
To make this system work it is crucial to commit to the trunk often, so that the changes are of manageable size. You do not want to have the situation when you have to review a year's worth of somebody's code.