Reading Nuke's original post, and the responses to it so far, I realized that there are different reasons for doing a code review, and the nature of the review depends on your reasons for doing the review. Some reasons I can think of off the top of my head:

• to find and fix bugs, security holes, and the like
• to find and fix design flaws and/or plan for refactoring
• to facilitate knowledge transfer to new programmers on a project
• as part of an employee performance review
• as a part of a job interview

Most likely, no single code review will be done for all of these reasons. Depending on the reasons for the review, the "important parts" of a review will be different.

Of course, these observations are made in a world larger than just PerlMonks.

Alan