Best practices for code review

No one denies the function of code review (Code review and review) to improve code quality. But how does one review code? There are some methods and techniques. Improper methods will waste a lot of time and cause inefficiency. Too tight processes will greatly reduce productivity and process loose. It is difficult to know the effect of code review or even whether code review is performed, are difficult to judge.

Here are 11 best practices for code review:

1. Less than 200 ~ 400 lines of code
2. Try to achieve a proper inspection speed: less than 300 ~ 500 lines of code
3. There is sufficient time, speed, and careful check, but not more than 60 ~ 90 minutes
4. Before review, the Code author should comment out the code
5. Establish quantitative objectives and obtain relevant indicator data, so as to continuously improve the process
6. Using checklist will certainly improve the results of both parties (author and reviewer)
7. Verify if the defect is actually repaired
8. Management Personnel should create a good atmosphere (Culture) so that everyone can actively deal with the discovery of defects, find enough defects, and only care about what the problem is and how it is caused, no matter who wrote the code
9. Measure tool ("Big Brother") is a double-edged sword.
10. Self-constraint: do as much as possible even if you do not have time to complete all code checks.
11. Lightweight code review is efficient and feasible, and can effectively detect defects

For more information, see[PDF]Best practices for peer code review (www.smartbearsoftware.com)
Or code reviews-http://dotnet.org.za/cjlotz/archive/2007/08/28/code-reviews.aspx

There is a comment that will be helpful to everyone, such as emphasizing the purpose of code review and the use of code static analysis tools:

I think the first thing you need to figure out is what kind of errors are you expecting to find during inspections. it must exist a clear idea of the goal of the review and all participant accounts share this idea. if this is not defined you may have reviews wasting time in discussions about variable names, indentation, code comments, message descriptions, or any other topic.

In my company for example, we don't look for code conventions compliance, we use automatic tools to ensure that. we run static analysis tool on our code before inspections, therefore we don't look for the type of errors that this tool can easily report. but we do look for compliance with the design: Is the Code Implementing the defined design appropriately? Are all Exception conditions handled following the design?

One useful thing that I did in the past to define our goal for code reviews is to read different code inspection checklists available online and identify the items that I considered useful for our reviews. then, based on that list I agreed with the team the aspects that we shoshould check in our code reviews. in that way we focused our effort and everyone was on the same page during the review.

Other references:

• One of the best practices for Software Quality Assurance: Code Review and Case Review
• Bug Analysis: lays the foundation for Bug prevention
• Extreme inspections: http://www.gilb.com/community/tiki-page.php? Pagename = Inspection
• Http://www.gilb.com/community/tiki-download_file.php? Fileid = 64