mirror of
https://github.com/github/codeql.git
synced 2026-04-25 08:45:14 +02:00
43 lines
1.3 KiB
XML
43 lines
1.3 KiB
XML
<!DOCTYPE qhelp PUBLIC
|
|
"-//Semmle//qhelp//EN"
|
|
"qhelp.dtd">
|
|
<qhelp>
|
|
<overview>
|
|
<p>
|
|
This metric measures the number of lines of text that have been added, deleted
|
|
or modified in files below this location in the tree.
|
|
</p>
|
|
|
|
<p>
|
|
Code churn is known to be a good (if not the best) predictor of defects in a
|
|
code component (see e.g. [Nagappan] or [Khoshgoftaar]). The intuition is that
|
|
files, packages or projects that have experienced a disproportionately high
|
|
amount of churn for the amount of code involved may have been harder to write,
|
|
and are thus likely to contain more bugs.
|
|
</p>
|
|
|
|
</overview>
|
|
<recommendation>
|
|
|
|
<p>
|
|
It is a fact of life that some code is going to be changed more than the rest,
|
|
and little can be done to change this. However, bearing in mind code churn's
|
|
effectiveness as a defect predictor, code that has been repeatedly changed
|
|
should be subjected to vigorous testing and code review.
|
|
</p>
|
|
|
|
</recommendation>
|
|
<references>
|
|
|
|
|
|
<li>
|
|
N. Nagappan et al. <em>Change Bursts as Defect Predictors</em>. In Proceedings of the 21st IEEE International Symposium on Software Reliability Engineering, 2010.
|
|
</li>
|
|
<li>
|
|
T. M. Khoshgoftaar and R. M. Szabo. <em>Improving code churn predictions during the system test and maintenance phases</em>. In ICSM '94, 1994, pp. 58-67.
|
|
</li>
|
|
|
|
|
|
</references>
|
|
</qhelp>
|