about General Class-Level Information
- - - -about Architecture
- - - -about best practices
- - - - - - --This metric measures the number of lines of text that have been added, deleted -or modified in files below this location in the tree. -
- --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. -
- --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. -
- --This metric measures the number of different authors (by examining the -version control history) -for files below this location in the tree. (This is a better version -of the metric that counts the number of different authors using Javadoc -tags.) -
- --Files that have been changed by a large number of different authors are -by definition the product of many minds. New authors working on a file -may be less familiar with the design and implementation of the code than -the original authors, which can be a potential source of bugs. Furthermore, -code that has been worked on by many people, if not carefully maintained, -often ends up lacking conceptual integrity. For both of these reasons, any -code that has been worked on by an unusually high number of different people -merits careful inspection in code reviews. -
- --There is clearly no way to reduce the number of authors that have worked -on a file - it is impossible to rewrite history. However, files highlighted -by this metric should be given special attention in a code review, and may -ultimately be good candidates for refactoring/rewriting by an individual, -experienced developer. -
- - - --This metric measures the total number of file-level changes made to files -below this location in the tree. For an individual file, it measures the -number of commits that have affected that file. For a directory of files, it -measures the sum of the file-level changes for each of the files in the -directory. -
- -
-For example, suppose we have a directory containing two files, A and B. If the
-number of file-level changes to A is 100, and the number of
-file-level changes to B is 80, then the total number of
-file-level changes to the directory is 180. Note that this is
-likely to be different (in some cases very different) from the number of
-commits that affected any file in the directory, since more than one file can
-be changed by a single commit. (Note what would happen if we performed
-80 commits on A and B, followed by another 20
-commits on A alone - the total number of file-level changes would be
-180, but the number of commits involved would be
-100.)
-
-This metric measures the average number of co-committed files for the files -below this location in the tree. -
- -
-A co-committed file is one that is committed at the same time as a given file.
-For instance, if you commit files A, B and C together, then B and C would be
-the co-committed files of A for that commit. The value of the metric for an
-individual file is the average number of such co-committed files over all
-commits. The value of the metric for a directory is the aggregation of these
-averages - for instance, if we are using max as our aggregation
-function, the value would be the maximum of the average number of co-commits
-over all files in the directory.
-
-An unusually high value for this metric may indicate that the file in question -is too tightly-coupled to other files, and it is difficult to change it in -isolation. Alternatively, it may just be an indication that you commit lots of -unrelated changes at the same time. -
- --Examine the file in question to see what the problem is. -
- --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. -
- --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]. -
- --High numbers of re-commits can be addressed on two levels: preventative and -corrective. -
- -
-This metric measures the number of recent changes to files that have occurred
-below this location in the tree. A recent change is taken to mean a change
-that has occurred in the last 180 days.
-
-All code that has changed a great deal may be more than usually prone to -defects, but this is particularly true of code that has been changing -dramatically in the recent past, because it has not yet had a chance to be -properly field-tested in order to iron out the bugs. -
- --There is more than one reason why a file may have been changing a lot -recently: -
- -