Is there an industry standard or good practices for the code review activity?

Question

An SDLC explains how an item of software can be defined, modeled, developed, tested, released and supported. The SDLC is split into any number of phases, depending on the methodology used (Waterfall, SCRUM, etc.). Each phase will contain activities, some of which are test-related. One of the activities is generally called Code Review, which is where developers check the code that has been written.

Does anybody have an industry-standard definition of the term 'Code Review'? I was wondering if anyone has come across an 'official' (e.g. ISO) definition.

Answer 1

How about the definition as on the Wikipedia: Code review is systematic examination of computer source code.

I think the main added value of code reviews is knowledge sharing and not finding defects. That's why I would like to add a bit of more text, how about this:

Code review is systematic examination of computer source code with the goal of sharing knowledge and minimizing defects.

After reading The Best Kept Secrets of Peer Code Review by SmartBear I really think the lightweight checklist-based code review they describe is a good fit for a standard for code-reviews.

The checklist-based code review works a bit as following:

• Programmer reviews his/her own code. Puts any found mistakes on a checklist and dates the last occurrence
• Use this same checklist to check each line of code of other programmers, update the occurrence field when you find an issue
• Use part of checklist of team members as a team checklist
• Make sure the list does not become to long, max 20 items
• Time-box code review sessions, with a max of one hour
• After a while remove items that stop occurring from the checklist

This way you always have an list of issues the team members are making. They can learn from each others mistakes. If used correctly the team will stop making the same mistakes over time and thus can remove items from the checklist.

Answer 2

There is an IEEE standard for formal software inspections etc, which is a special form of reviews: IEEE Standard for Software Reviews and Audits, IEEE Std. 1028-2008

Furthermore, there is a definition of "code review" and "change-based code review" in the scientific paper "A Faceted Classification Scheme for Change-Based Industrial Code Review Processes" (http://dx.doi.org/10.1109/QRS.2016.19 or alternatively http://tobias-baum.de/rp/classification.pdf). This definition fits current industrial practices much better than the IEEE one. Caveat: I'm one of the authors.

Answer 3

There are many styles of reviewing. Systems such as Fagan Inspections aim to find most faults. They are very expensive but they claim very good results. At the other end there is "Hey Nigel, have a quick gander at this code please".

Perhaps every project manager has their own view on how to conduct reviews. I believe that most expect them to be quick to conduct and consume few man-hours.

Reviewing can be viewed as a way of reducing the risk of a bad system being provided to its users. Analysing the consequences of the risks should lead to a view on how much effort will be available for risk reduction. Part of that effort will be available for reviewing. But this also means that different projects need different styles of reviewing.

Answer 4

I am not personally aware of any 'industry' standard.

The best combination of practices that I have observed at several companies that do code review is:

• Tools that automatically fix non-code issues such as blank trailing lines, blank trailing spaces, incorrect use of tabs, etc.

• Tools such as linters and cops that report on code quality and suggest /recommend changes

• Tools and processes for human suggestions about code design, style, naming and approach such as the github Pull Request and code review process

More specifically good practices covered in code review generally lean to:

• DRY (Don't Repeat Yourself) code, so repeated sections are extracted and referenced once
• As few parameters as possible, each one factorially increases combinations
• Short classes over long, for instance 100 lines over 500 lines
• Short methods over long, ideally 3-5 lines per method
• Avoiding dependencies when possible
• Well named objects using full english
• Mocking and Stubbing for Unit Tests
• Avoiding over use of acronyms
• Page Objects for UI tests
• Good test coverage

There is good information at https://www.codeproject.com/Articles/524235/Codeplusreviewplusguidelines

which includes:

The main goals of code review are:

• To spot and fix defects early in the process.
• Better-shared understanding of the code base as team members learn from each other
• Helps to maintain a level of consistency in design and implementation.
• Helps to identify common defects across the team thus reducing rework.
• Builds confidence of stakeholders about technical quality of the execution.
• Uniformity in understanding will help interchangeability of team members in case of non-availability of any one of them.
• A different perspective. “Another set of eyes” adds objectivity. Similar to the reason for separating your coding and testing teams, peer reviews provide the distance needed to recognize problems.
• Pride/reward. Recognition of coding prowess is a significant reward for many programmers.
• Team cohesiveness. Working together helps draw team members closer. It also provides a brief respite from the isolation that coding often brings.

The main areas a reviewer is focusing on are as follows:

• Security
• Performance
• Thread Safety
• Functionality
• Error Handling
• Resource Leaks
• Control Structures
• General Unit Testing
• Comment and Coding Conventions

Answer 5

No. Neither the ISO nor any other standards organization has produced a standardized process for code review.

Answer 6

It is worth to have a look at Google Testing Blog.
They post different blogs how Test and Quality are handled at Google and part of it is related to Code Health and Code Review.

Answer 7

It is not an ISO standard, but Google published its code review guidelines, you can read them here: https://google.github.io/eng-practices/review/