Code reviews, the sanity check of software development.  They're a software engineering best practice initiative.  That's what a bullet point on my job description says, anyway.  Microsoft even calls them a best practice and has a slick how-to for C and C++:  http://msdn.microsoft.com/en-us/library/bb871031.aspx.

In a nutshell (a small nut) the idea is, you write some code, when you're done let me know, and then I look at it to see if it makes sense and is is free of glaring flaws.

We do code reviews all the time where I work.  I do at least one a week, and I ask other people to review my code... when I'm writing code not Word docs, all the time.  I get the occasional "why not just do this", and I occasionally I get to give it right back.  It's good.  It's a sanity check for the code.  It makes the software better; makes everyone (hopefully) better developers thanks to good feedback; and keeps maintenance costs low.

Now, here's the gaping hole: Code reviews are a sanity check on the code you wrote, not the code you didn't write.  See?  Makes perfect sense to me. 

When I look at code during a code review I'm looking at the code that you wrote.  I'm not necessarily looking for the subtle piece of logic that you left out that makes the whole feature work like the functional spec says it will.  For that matter, I may not even know what feature you're working on.  All I need to know is, what is this piece of code supposed to do, not what the entire feature consists of.  Code in and of itself does not a feature make.

Code reviews can not, nor should they, substitute for good testing, QA, and verification and validation (V&V for you software engineer types).  You still need to have some black-box testing mechanism in place to ensure that the final software does what it's supposed to do.  Code reviews can not always catch the missing logic or missing piece of code that makes sure there's money in the account before debiting it (disclaimer: that example is obviously obvious purposefully on purpose).  Having a test plan and having good QA is the only way to ensure that the software works (mostly - see "good enough").

Cheers,

Goody