so: "You've got that wired in backwards", "Tim built one of those over here", "When we implement foo, that'll bar" & "That's a security hole because ...." are good.
But coding standards don't prevent logic errors, or requirements misunderstandings. Even the best developers make those kinds of mistakes and we catch a significant fraction of them during code reviews.
The other major benefit of consistently doing code reviews is learning. The attendees often pick up useful new techniques. And you spread knowledge of the code base around the team, which reduces the organization's dependence on any one developer and also brings out opportunities for code reuse.
If that were so, then you could standardize the production of good code.
You're seriously wasting time if your code reviews could be done by a batch of regular expressions and a cron job, ala http://search.cpan.org/dist/Perl-Critic/lib/Perl/Critic.pm
I always thought the point was to keep things well factored: find hard to spot duplication or inconsistencies in disparate areas of the code, point out a library/api that could have done the task better, etc.
Well defined, zero tolerance, guidelines virtually eliminate the need for code reviews. Variable naming, standard routines, syntax, how to do iteration, branching, common functions, etc., etc. etc., should all be outlined clearly, agreed upon, and adhered to.
I prefer to look at it this way...
Code Review: No one gets out of this room alive until this is right (whatever that means).
Standards Compliance: Wanna play? Good. Follow the rules.
Oh, and please don't give me that age old argument about how standards limit creativity; if this small price for quality software is too limiting for you, then go play by yourself.