ode reviews are widely recognized as one of the most effective ways to detect bugs, performance issues, and coding errors of all sorts. And by promoting discussion and knowledge sharing, code reviews also have the rare ability to improve both the quality of your code and the skill of your developers.
A code review involves presenting and discussing the code for a project. The aim is to spot potential problems and check that the software architecture and design rules are being applied correctly. Reviewers generally use a checklist of common errors and applicable coding standards and best practices to ensure that they examine the code thoroughly.
The following are the different types of code review, which vary mostly in degree of formality:
- A code walkthrough simply involves developers meeting to review code.
- Code reading is a little more formal, with reviewers independently examining a designated block of source code.
- Code inspection, the most formal of all code reviewing techniques, was introduced by Michel Fagan in 1976. Code inspections follow a rigorous formal process where trained participants are assigned predefined roles, such as moderator, scribe, author, and reviewer.
Code reviews can also be done individually, either in preparation for a peer review or just as part of good programming practices. Indeed, the Software Engineering Institute recommends personal code reviews as a best practice of its Personal Software Process. This involves simply reading through your code and using a review checklist to look for errors.
The efficiency of code reviews has been well studied and well documented. IBM reported detecting 80-90 percent of defects by using formal code inspection techniques, as well as overall schedule savings of 10-30 percent (Fagan, M.E., Advances in Software Inspections, July 1986, IEEE Transactions on Software Engineering, Vol. SE-12, No. 7, Page 744-751). A code review done by an experienced developer can help raise and fix many different types of potential problems, such as:
- Inefficient and/or poorly performing code
- Security issues
- Incorrect business logic
- Incorrect use of project or industry best practices and standards
- Just about anything else!
In addition to the obvious benefits of reducing defects and improving code quality, code reviews have another thing going for them. They are (or should be) an excellent way to share knowledge and discuss code design and architecture in a constructive, applied manner. They ensure that all developers involved in a project are familiar with applicable industry best practices and that they have a good handle on the specific architectural and design techniques used.
However, despite their obvious advantages, code reviews are among the least used of all the recommended industry best practices. They often have a bad reputation among developers, who may fear criticism of their code and who generally dislike "wasting time" in too many meetings. Indeed, code reviews can be long and tedious, which means they are rarely done with any real assiduity. Human nature being what it is, code reviews will often tend to focus on surface issues, such as conformity to basic coding conventions, and neglect the harder aspects, such as potential errors, performance issues, and understanding and verifying the design and business logic behind the code.
Automating the Review Process
A great help in implementing code reviews in development is automation. Software tools can help you automate a great deal of the review process, leaving you to concentrate on the more interesting aspects that only a human reviewer can check: faulty business logic, adherence to project design and architecture guidelines, possible optimizations, and so forth.
A good tool for this job is PMD, a static code analyzer capable of automatically detecting a wide range of potential defects and unsafe or non-optimized code. While other tools, such as Checkstyle, can verify that coding conventions and standards are respected, PMD focuses on preemptive defect detection.