Lorna Mitchell has posted a list of helpful tips to perform good code reviews on submissions before even trying to run the code for correctness.

I do a lot of code reviewing, both in my day job as principal developer and also as an open source maintainer. Sometimes it seems like I read more code than I write! Is that a problem? I'm tempted to say that it isn't. To be a good writer, you must be well-read; I believe that to be a good developer, you need to be code-omnivorous and read as much of other people's code as possible. Code reviews are like little chapters of someone else's code to dip into.

She offers several tips you can follow to make the reviews you do more effective including:

• Ensuring you understand the change
• Are the changes where you'd expect?
• Does the commit history make sense
• Evaluate the diff to ensure the changes themselves are valid

She only then recommends trying out the code. Following the suggestions above can help ferret out issues that may be hidden by just running the code and not fully looking into the changes.

Brandon Savage has his own response to the "comments are harmful" post over on the PHP in Action blog:

There's a lot of good advice, especially about writing clean code. But the article fails to address a good number of really critical details and to some degree misses the point of Eli's article.

He mentions these points - the value of writing comments before hand, the usefulness of descriptive comments, how they can be used as a todo pointing to future development and using them to share the knowledge and let other people in on what you're thinking.