Code Review Metrics

(Redirected from Code review Metrics)
Jump to: navigation, search
««Application Threat Modeling«« Main
(Table of Contents)




Relative metrics are a representation of an attribute that cannot be directly measured, and are subjective and reliant on the context of where the metric was derived. There is no definitive way to measure such an attribute. Multiple variables are factored into an estimation of the degree of testing difficulty, and any numeric representation or rating is only an approximation and is subjective.

Some Metric Benefits



SCR Process.jpg


Secure Development Metrics

Defect Density


Lines of Code (LOC)


Function Point


Risk Density


4 High Risk Defects per 1000 (Lines of Code)
2 Medium Risk Defects per 3 Function Points

Path complexity/complexity-to-defect/cyclomatic complexity


CC = Number of decisions +1

A decision could be considered commands such as:

and so on.....



0-10: Stable code. Acceptable complexity
11-15: Medium Risk. More complex

Review Process Metrics

Inspection Rate


Defect Detection Rate

This metric measures the defects found per unit of time. Again, can be used to measure performance of the code review team, but not to be used as a quality measure. Defect detection rate would normally increase as the inspection rate (above) decreases.

Code Coverage

Measured as a % of LoC of function points, the code coverage is the proportion of the code reviewed. In the case of manual review we would aim for close to 100%, unlike automated testing wherein 80-90% is considered good. In order to ensure that the code coverage standards are met, some organizations might implement a safety check during the build process, so the build will fail if there are any piece of code that has not been tested or if it the coverage is under the desired percentage. The higher the percentage of code coverage, the better to ensure quality and prevent logic errors.

Defect Correction Rate


Reinspection Defect Rate

The rate at which upon re-inspection of the code more defects exist, some defects still exist, or other defects manifest through an attempt to address previously discovered defects.

««Application Threat Modeling«« Main
(Table of Contents)