The Importance of Static Code Analysis

Yes, that is a play on the words by Alexander Pope and to err is indeed human, and even though developers are a methodical and meticulousgroup, mistakes do happen when writing code. The software is written by humans and often riddled with mistakes, and for this reason,code review is a vital element of the finished product. There are code review tools and software, but they miss an important point of the code review process.

What is code review

Code review is the systematic examination of source code. Its main aim is to find mistakes that werenot taken care of in the developmental phase and to improve the overall quality of the software. These reviews can be done by other authors of thecode, peer reviewers or quality assurance (QA) testers, as well as code review tools that are automated testers.

Developers tasked with code reviews usually ask the following questions:

  1. Is there any clear logic error?
  2. Based on the requirements; are all the cases completely implemented?
  3. Does the new code conform to existing style guidelines?
  4. Are new code analysis tools sufficient for the new code or does the analysis tool code need to be rewritten for the changes in the code?

Why you should review code

The purpose of code review differs from enterprise to enterprise, however, the fundamental goals are the same. The basic review objectives consist of the following:

  1. To ensure defect-free, and well-documented software;
  2. To ensure that the software complies with enterprise coding standards;
  3. To teach new developers and to share knowledge between developers;
  4. To ensure maintainability, security, consistent end-user documentation, acceptable comments in the code, complete unit test and scalability.

How to implement a code review

Every developer has his or her own method for conducting a review, however, the general consensus amongst them is to start with a code review checklist. A code review checklist will ensure that all reviewers look out for errors commonly missed by automated review tools, and is the best method of ensuring you find any omissions. Also, it is a best practice for code authors to ensure they have done their due diligence.

Below are fivecode review methodologies to help you through the process:

1. Review fewer than 200 – 400 lines of code at a time

According to a Cisco code review study, for maximum effectiveness, developers should not review more than 400 lines of code (LOC) at a time. More than 400 LOC will diminish the reviewer’s ability to detect faults and omissions.

2. Take no more than 60 – 90 minutes to review

There have been many studies conducted on people’s ability to concentrate and for how long they are able to do so. According to most findings, people are not able to concentrate for longer than 60 to 90 minutes, after this time their ability to find faults and omission in thecode will reduce.

3. Set a goal for an inspection rate of less than 500 LOC/hour

Code review is a timeous process, but pushing through as many lines as possible will not do the process any justice. In this case, faster is certainly not better. Racing through the process will only result in faults being overlooked or missed completely.

4. Capture review metrics and goals for improvement

At the start of the review process, you need to set achievable goals and ensure that you have metrics in place. These metrics will show if you have achieved these goals, as well as help you improve your processes for future reviews.

5. Confirm that defects are fixed

You might think that this is obvious, but sometimes it is an overlooked aspect of the review process. Faults are detected but never resolved. Make sure you have processes in place that allows the reviewers to log faults and discuss them with the author. Authors then fix the problems, notify the reviewers and the reviewers then verify that the issue/s are resolved.

Reviews are time-consuming, but very effective in finding errors. Not conducting a code review will ultimately result in loss of revenue, irate customers and a product no one wants.

Comments are closed