How do you contrast Code Review, as a StackExchange site, with a real-life code review?
If there are differences, are these differences acceptable?
How does Code Review bridge the gap between a newcomer's mental model of what a code review is and expectations of the Code Review site?
Are these efforts sufficient?
A few things that come to my mind and which could differ from a "real-life" code review:
Your review remains: here, code review isn't an oral process, it's a written one, and it is made to remain. We try to write interesting answers, but also to structure them, to include some nice mathematical syntax when needed, some images from time to time... The review will stay and may help other people, while many real-life code reviews will only help one person.
Your original code remains: we strive to keep the original code so that the answers are not invalidated for as long as possible. In real-world code reviews, the original code isn't guaranteed to remain either (source control software exists, but there may still be reasons for your original code to be deleted at some point, be it intentional or not).
Reviewers are reviewed: you don't have one, but several people reviewing your code. And the answers from some people will be built upon to create new answers. Hopefully, it helps to give the best possible advice.
We are volunteer: you are not guaranteed to get a review, and the reviews are not guaranteed to be reviewed either. You can only ask for help, you can't demand it.
That all depends.... what does a real-life code review look like?
I have been through many of them, and they are all different.
Trying to relate this site to a dynamic, fluid, poorly standardized process, is not a realistic endeavour, and the results of such an analysis would do little to impact the 'gap' of a newcomer's expectations. To be fair, no newcomer will know what a real-life code review is, and experienced people will know to expect something different each time.
As a consequence, since it is hard to assess what efforts would be required, it is similarly hard to decide whether the efforts are sufficient.
If your concern is about the name 'Code Review', well, it is clear that what happens here is nothing like what happens in a 'real' code review (for a start, in a real code review you have real people in a real room, with a real salary, and a real deadline, etc.).
In essence, Mu.
Approaching this from another perspective, this also depends on the code review format of choice in real-life (cough):
Whether these differences are acceptable is up to both the reviewer and reviewee. Sometimes you just need an extra pair of eyes within the next 5 minutes, or sometimes you want to leverage on iterative code reviews to compare the evolution of the proposed changes.
The difference between Code Review and real life reviews is that the latter are a regular activity involving the same participants, and so over time a shared expertise can be developed and written down.
After some problem has come up a few times in review, it gets added to the local coding standard or pre-review checklist, and people learn to spot the problem themselves and fix it before it gets as far as review, so that after a while, the basic problems no longer come up, and you can use the time to analyze the code more deeply. (If this isn't happening in your real-life reviews, then something's wrong.)
Whereas at Code Review, most questions are from someone who's new to the review process, and so they mostly have the same basic problems (lack of documentation, lack of tests, poor functional decomposition or class hierarchy, poorly chosen names, poor handling of error conditions, failure to make full use of the standard library, and so on).
