Browse Prior Art Database

Complexity measure for code changes Disclosure Number: IPCOM000238889D
Publication Date: 2014-Sep-24
Document File: 2 page(s) / 30K

Publishing Venue

The Prior Art Database


Defect prediction based on code changes received little attention. Most work on defect prediction focuses on static metrics, such as cyclomatic complexity, of a given version of a software artifact. Other work counts the number of lines that were changed without considering the semantics of the change. We propose a complexity measure of change in code that gives higher values for changes to complex logic and low value to less significant changes.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 2

Complexity measure for code changes

The field of defects prediction and test suite minimization receives a lot of attention. However, most of the relevant research collects historical information on defects at specific locations and uses this as a predictor for any new changes [1]. Other work correlates between metrics and defects based on the entire code without taking into consideration the magnitude of changes performed on this code, or if there were any changes at all for that matter [2]. Most test suite minimization techniques look at the current version of the code and prioritize tests based on dependencies between code elements or based on the code's traceability to requirements description[3].

The most relevant research looks at the number of added/removed code lines without taking the semantics of the change into consideration [4,5].

    We propose a measure of complexity of a change in the code (at any level of granularity: functions, methods, classes, complete files) that takes into account the exact changes applied to the code. The proposed solutions analyzes two versions of the same piece of code and calculates the complexity of a change for each function (or other element). The complexity is computed using known cyclomatic complexity [7] for functions/methods and using WMC [8] metric for classes/files.

This calculated complexity measures can be used for defects prediction (the larger the value compared to other changes, the higher the probability of having a defect). It can be also used for test cases prioritization (changes with the highest complexity measures should be tested first).

[1]Graves, T.L.; Karr, A.F.; Marron, J.S.; Siy, H., "Predicting fault incidence using software change history," Software Engineering, IEEE Transa...