mirror of
https://github.com/github/codeql.git
synced 2026-02-20 08:53:49 +01:00
54 lines
1.4 KiB
XML
54 lines
1.4 KiB
XML
<!DOCTYPE qhelp PUBLIC
|
|
"-//Semmle//qhelp//EN"
|
|
"qhelp.dtd">
|
|
<qhelp>
|
|
<overview>
|
|
<p>
|
|
This metric measures the number of file re-commits that have occurred below
|
|
this location in the tree. A re-commit is taken to mean a commit to a file
|
|
that was touched less than five days ago.
|
|
</p>
|
|
|
|
<p>
|
|
In a system that is being developed using a controlled change process (where
|
|
changes are not committed until they are in some sense 'complete'), re-commits
|
|
can be (but are not always) an indication that an initial change was not
|
|
successful and had to be revisited within a short time period. The intuition
|
|
is that the original change may have been difficult to get right, and hence
|
|
the code in the file may be more than usually defect-prone. The concept is
|
|
somewhat similar to that of 'change bursts', as described in [Nagappan].
|
|
</p>
|
|
|
|
</overview>
|
|
<recommendation>
|
|
|
|
<p>
|
|
High numbers of re-commits can be addressed on two levels: preventative and
|
|
corrective.
|
|
</p>
|
|
|
|
<ul>
|
|
<li>
|
|
On the preventative side, a high number of re-commits may be an indication
|
|
that your code review process needs an overhaul.
|
|
</li>
|
|
|
|
<li>
|
|
On the corrective side, code that has experienced a high number of re-commits
|
|
should be vigorously code reviewed and tested.
|
|
</li>
|
|
</ul>
|
|
|
|
|
|
</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>
|
|
|
|
|
|
</references>
|
|
</qhelp>
|