Here is a list of discussion points that code reviewers; peer developers need to take into consideration. This list is not comprehensive but a suggestion starting point for an enterprise to make sure code reviews are effective and not disruptive and a source of discourse. If code reviews become a source of discourse within an organization the effectiveness of finding security, functional bugs will decline and developers will find a way around the process. Being a good code reviewer requires good social skills, and is a skill that requires practice just like learning to code.
• You don’t have to find fault in the code to do a code review. If you always find something to criticize your comments will loose credibility.
• Do not rush a code review. Finding security and functionality bugs is important but other developers or team members are waiting on you so you need to temper your do not rush with the proper amount urgency.
• When reviewing code you need to know what is expected. Are you reviewing for security, functionality, maintainability, and/or style? Does your organization have tools and documents on code style or are you using your own coding style? Does your organization give tools to developers to mark unacceptable coding standards per the organizations own coding standards?
• Before beginning a code review does your organization have a defined way to resolve any conflicts that may come up in the code review by the developer and code reviewer?
• Does the code reviewer have a defne set of artifacts that need to be produce as the result of the code review?
• What is the process of the code review when code during the code review needs to be changed?
• Is the code reviewer knowledgeable about the domain knowledge of the code that is being reviewed? Ample evidence abounds that code reviews are most effective if the code reviewer is knowledgeable about the domain of the code I.e. Compliance regularizations for industry and government, business functionality, risks, etc.
Source: OWASP Code Review Guide 2.0