Toward understanding the rhetoric of small source code changes

Purushothaman, Ranjith; Perry, Dewayne E.

doi:10.1109/tse.2005.74

Cited by 166 publications

(112 citation statements)

References 24 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…The focus of a study presented by Purushothaman and Perry [67,68] was to understand the impact of small changes, particularly one-line changes, with regards to faults, the relationship between different types of changes (i.e., add, delete, and modify), the reason for the change (i.e., corrective, adaptive, and perfective), and dependencies between changes. A change was considered to be a one-line change if there was at least one modification to a single line, at least one line was replaced by a single line (i.e., multiple lines deleted followed by an addition of a single line), a new statement was added between existing lines, or a single line was deleted.…”

Section: Characteristics Of Small Changesmentioning

confidence: 99%

A survey and taxonomy of approaches for mining software repositories in the context of software evolution

Kagdi

Collard

Maletic

2007

J. Softw. Maint. Evol.: Res. Pract.

313

195

View full text Add to dashboard Cite

SUMMARYA comprehensive literature survey on approaches for mining software repositories (MSR) in the context of software evolution is presented. In particular, this survey deals with those investigations that examine multiple versions of software artifacts or other temporal information. A taxonomy is derived from the analysis of this literature and presents the work via four dimensions: the type of software repositories mined (what), the purpose (why), the adopted/invented methodology used (how), and the evaluation method (quality). The taxonomy is demonstrated to be expressive (i.e., capable of representing a wide spectrum of MSR investigations) and effective (i.e., facilitates similarities and comparisons of MSR investigations). Lastly, a number of open research issues in MSR that require further investigation are identified. Copyright

show abstract

Section: Characteristics Of Small Changesmentioning

confidence: 99%

A survey and taxonomy of approaches for mining software repositories in the context of software evolution

Kagdi

Collard

Maletic

2007

J. Softw. Maint. Evol.: Res. Pract.

313

195

View full text Add to dashboard Cite

show abstract

“…This is consistent with trends seen in industrial practice: most human-generated bug fixes are fairly short [141].…”

Section: While! Conditionsupporting

confidence: 89%

“…This is especially true because most bug fixes are quite small, consisting of changes to 10 or 20 lines of code [141] even in systems that comprise millions of lines of code. Finding the appropriate location to change to affect a very particular piece of behavior can be like finding a needle in a haystack.…”

Section: How Do Humans Fix Bugs?mentioning

confidence: 99%

Automatic Program Repair Using Genetic Programming

Goues¹

View full text Add to dashboard Cite

Software quality is an urgent problem. There are so many bugs in industrial program source code that mature software projects are known to ship with both known and unknown bugs [1], and the number of outstanding defects typically exceeds the resources available to address them [2]. This has become a pressing economic problem whose costs in the United States can be measured in the billions of dollars annually [3].A dominant reason that software defects are so expensive is that fixing them remains a manual process. The process of identifying, triaging, reproducing, and localizing a particular bug, coupled with the task of understanding the underlying error, identifying a set of code changes that address it correctly, and then verifying those changes, costs both time [4] and money, and the cost of repairing a defect can increase by orders of magnitude as development progresses [5]. As a result, many defects, including critical security defects [6], remain unaddressed for long periods of time [7]. Moreover, humans are error-prone, and many human fixes are imperfect, in that they are either incorrect or lead to crashes, hangs, corruption, or security problems [8]. As a result, defect repair has become a major component of software maintenance, which in turn consumes up to 90% of the total lifecycle cost of a given piece of software [9].Although considerable research attention has been paid to supporting various aspects of the manual debugging process [10,11], and also to preempting or dynamically addressing particular classes of vulnerabilities, such as buffer overruns [12,13], there exist virtually no previous automated solutions that address the synthesis of patches for general bugs as they are reported in real-world software.The primary contribution of this dissertation is GenProg, one of the very first automatic solutions designed to help alleviate the manual bug repair burden by automatically and generically patching bugs in deployed and legacy software. GenProg uses a novel genetic programming algorithm, guided by test cases and domain-specific operators, to affect scalable, expressive, and high quality automated repair. We present experimental evidence to substantiate our claims that GenProg can repair multiple types of bugs in multiple types of programs, and that it can repair a large proportion of the bugs that human developers address in practice (that it is expressive); that it scales to real-world system sizes (that it is scalable); and that it produces repairs that are of sufficiently high quality. Over the course of this evaluation, we contribute new benchmark sets of real bugs in real open-source software and novel experimental frameworks for quantitatively evaluating an automated repair technique. We also contribute a novel characterization of i Chapter 0Abstract ii the automated repair search space, and provide analysis both of that space and of the performance and scaling behavior of our technique.General automated software repair was unheard of in 2009. In 2013, it has its own multi-paper s...

show abstract

“…Purushothaman and Perry analyzed the impact of small changes, especially oneline changes, about faults, relations between changes (add, delete, and modify), reasons of changes (corrective, adaptive, and perfective), and dependencies between changes [83], [84]. They derived some empirical results as follows: About 10% changes were one-line changes; 50% changes were at most about 10 loc (line of codes) changes; 95% of changes were 50 loc changes; Most changes were 'adaptive' and related to 'code addition'.…”

Section: Purpose Of Msr Analysismentioning

confidence: 99%