How, and why, process metrics are better

Rahman, Foyzur; Dévanbu, Prémkumar

doi:10.1109/icse.2013.6606589

Cited by 258 publications

(249 citation statements)

References 26 publications

Supporting

Mentioning

235

Contrasting

Unclassified

Order By: Relevance

“…Specifically, we evaluate whether ordering files by entropy will better guide us to identifying buggy files than traditional logistic regression and random forest based DP. DP is typically used at release-time to predict post-release bugs [35,57,42,36,11]; so, for this comparison we use the post release bug data collected in Phase-II. DP is implemented using two classifiers: logistic regression (LR) [43,42] and Random Forest (RF), where the response is a binary variable indicating whether a file is buggy or not.…”

Section: Rq2 Are Buggy Lines Less "Natural" Than Bug-fix Lines?mentioning

confidence: 99%

“…DP is typically used at release-time to predict post-release bugs [35,57,42,36,11]; so, for this comparison we use the post release bug data collected in Phase-II. DP is implemented using two classifiers: logistic regression (LR) [43,42] and Random Forest (RF), where the response is a binary variable indicating whether a file is buggy or not. The predictor variables are the process metrics from [42,11], such as #developers, #file-commit, code churn, and previous bug history; prior research shows that process metrics are better predictors of file level defects [42].…”

Section: Rq2 Are Buggy Lines Less "Natural" Than Bug-fix Lines?mentioning

confidence: 99%

“…DP is implemented using two classifiers: logistic regression (LR) [43,42] and Random Forest (RF), where the response is a binary variable indicating whether a file is buggy or not. The predictor variables are the process metrics from [42,11], such as #developers, #file-commit, code churn, and previous bug history; prior research shows that process metrics are better predictors of file level defects [42]. For each project, we train our model on one release and evaluate on the next release: a defectproneness score is assigned to every file under test.…”

Section: Rq2 Are Buggy Lines Less "Natural" Than Bug-fix Lines?mentioning

confidence: 99%

See 2 more Smart Citations

On the "naturalness" of buggy code

Ray

Hellendoorn

Godhane

et al. 2016

Proceedings of the 38th International Conference on Software Engineering

Self Cite

206

141

View full text Add to dashboard Cite

Real software, the kind working programmers produce by the kLOC to solve real-world problems, tends to be "natural", like speech or natural language; it tends to be highly repetitive and predictable. Researchers have captured this naturalness of software through statistical models and used them to good effect in suggestion engines, porting tools, coding standards checkers, and idiom miners. This suggests that code that appears improbable, or surprising, to a good statistical language model is "unnatural" in some sense, and thus possibly suspicious. In this paper, we investigate this hypothesis. We consider a large corpus of bug fix commits (ca. 7,139), from 10 different Java projects, and focus on its language statistics, evaluating the naturalness of buggy code and the corresponding fixes. We find that code with bugs tends to be more entropic (i.e. unnatural), becoming less so as bugs are fixed. Ordering files for inspection by their average entropy yields cost-effectiveness scores comparable to popular defect prediction methods. At a finer granularity, focusing on highly entropic lines is similar in cost-effectiveness to some well-known static bug finders (PMD, FindBugs) and ordering warnings from these bug finders using an entropy measure improves the cost-effectiveness of inspecting code implicated in warnings. This suggests that entropy may be a valid, simple way to complement the effectiveness of PMD or FindBugs, and that search-based bug-fixing methods may benefit from using entropy both for fault-localization and searching for fixes.

show abstract

Section: Rq2 Are Buggy Lines Less "Natural" Than Bug-fix Lines?mentioning

confidence: 99%

Section: Rq2 Are Buggy Lines Less "Natural" Than Bug-fix Lines?mentioning

confidence: 99%

Section: Rq2 Are Buggy Lines Less "Natural" Than Bug-fix Lines?mentioning

confidence: 99%

See 1 more Smart Citation

On the "naturalness" of buggy code

Ray

Hellendoorn

Godhane

et al. 2016

Proceedings of the 38th International Conference on Software Engineering

Self Cite

206

141

View full text Add to dashboard Cite

show abstract

“…The change history of source codes provides information that can help predict fault-prone files [39]. For example, a source code file that was fixed very recently is more likely to still contain bugs than a file that was last fixed long time in the past, or never fixed.…”

Section: Bug-fixing Recencymentioning

confidence: 99%

“…Correspondingly, the source code is syntactically parsed into methods and the features are designed to exploit method-level measures of relevance for a bug report. It has been previously observed that software process metrics (e.g., change history) are more important than code metrics (e.g., size of codes) in detecting defects [39]. Consequently, we use the change history of source code as a strong signal for linking fault-prone files with bug reports.…”

Section: Introductionmentioning

confidence: 99%

Learning to rank relevant files for bug reports using domain knowledge

Bunescu

Liu

2014

Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering

247

202

View full text Add to dashboard Cite

When a new bug report is received, developers usually need to reproduce the bug and perform code reviews to find the cause, a process that can be tedious and time consuming. A tool for ranking all the source files of a project with respect to how likely they are to contain the cause of the bug would enable developers to narrow down their search and potentially could lead to a substantial increase in productivity. This paper introduces an adaptive ranking approach that leverages domain knowledge through functional decompositions of source code files into methods, API descriptions of library components used in the code, the bug-fixing history, and the code change history. Given a bug report, the ranking score of each source file is computed as a weighted combination of an array of features encoding domain knowledge, where the weights are trained automatically on previously solved bug reports using a learning-to-rank technique. We evaluated our system on six large scale open source Java projects, using the before-fix version of the project for every bug report. The experimental results show that the newly introduced learning-to-rank approach significantly outperforms two recent state-of-the-art methods in recommending relevant files for bug reports. In particular, our method makes correct recommendations within the top 10 ranked source files for over 70% of the bug reports in the Eclipse Platform and Tomcat projects.

show abstract

Severity Factor (SF): An aid to developers for application of refactoring operations to improve software quality

Agnihotri

Chug

2023

J Software Evolu Process

View full text Add to dashboard Cite

Bad smells are certain flaws in the structure of the code that might not disturb the normal functioning of a program but negatively affects the software quality. Developers use refactoring as a corrective measure for the treatment of bad smells. The current study aids the developers in the application of refactoring by identifying the critical classes, that is, classes that are challenging to maintain and are of degraded quality. In this study, 10 quality metrics and 10 bad smells have been selected to conduct an investigation on different releases of five open‐source systems. A new metric, severity factor (SF) has been introduced that categorizes the classes of the selected systems into four criticality levels—severe, major, mid, and low. Also, the relationship between SF, criticality levels, and the refactoring operations has been analyzed. The findings show that 60% of the total classes have been affected by bad smells, and long statement is the most dominant smell present in 27.6% of the classes. The results show 84% of the refactoring operations have been performed on highly critical classes. Thus, the SF metric plays a crucial role in driving the developer's attention to the critical classes that need to be treated urgently.

show abstract

How, and why, process metrics are better

Cited by 258 publications

References 26 publications

On the "naturalness" of buggy code

On the "naturalness" of buggy code

Learning to rank relevant files for bug reports using domain knowledge

Severity Factor (SF): An aid to developers for application of refactoring operations to improve software quality

Contact Info

Product

Resources

About