Thresholds for Size and Complexity Metrics: A Case Study from the Perspective of Defect Density

• Published in: 2016 IEEE International Conference on Software Quality, Reliability and Security (QRS) pp. 191 - 201
• Main Authors: Yamashita, Kazuhiro, Changyun Huang, Nagappan, Meiyappan, Kamei, Yasutaka, Mockus, Audris, Hassan, Ahmed E., Ubayashi, Naoyasu
• Format: Conference Proceeding
• Language: English
• Published: IEEE 01-08-2016
• Subjects: Complexity theory; Couplings; Defect models; Java; Measurement; Software engineering; Software metrics; Software quality; Thresholds
• DOI: 10.1109/QRS.2016.31

Practical guidelines on what code has better quality are in great demand. For example, it is reasonable to expect the most complex code to be buggy. Structuring code into reasonably sized files and classes also appears to be prudent. Many attempts to determine (or declare) risk thresholds for various code metrics have been made. In this paper we want to examine the applicability of such thresholds. Hence, we replicate a recently published technique for calculating metric thresholds to determine high-risk files based on code size (LOC and number of methods), and complexity (cyclomatic complexity and module interface coupling) using a very large set of open and closed source projects written primarily in Java. We relate the threshold-derived risk to (a) the probability that a file would have a defect, and (b) the defect density of the files in the high-risk group. We find that the probability of a file having a defect is higher in the very high-risk group with a few exceptions. This is particularly pronounced when using size thresholds. Surprisingly, the defect density was uniformly lower in the very high-risk group of files. Our results suggest that, as expected, less code is associated with fewer defects. However, the same amount of code in large and complex files was associated with fewer defects than when located in smaller and less complex files. Hence we conclude that risk thresholds for size and complexity metrics have to be used with caution if at all. Our findings have immediate practical implications: the redistribution of Java code into smaller and less complex files may be counterproductive.