Studying the Impact of Clones on Software Defects

Selim, Gehan; Barbour, Liliane; Shang, Weiyi; Adams, Bram; Hassan, Ahmed E.; Zou, Ying

doi:10.1109/wcre.2010.11

Cited by 54 publications

(20 citation statements)

References 14 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The analyzed two open source systems and observed that only 1% to 3% of inconsistent changes introduce software defects. Selim et al [22] also analyzed the impact of cloned code on software defects. They found that the defect-proneness of cloned methods is specific to the system under study.…”

Section: Related Workmentioning

confidence: 99%

Is cloned code older than non-cloned code?

Krinke

2011

Proceedings of the 5th International Workshop on Software Clones

View full text Add to dashboard Cite

It is still a debated question whether cloned code causes increased maintenance efforts. If cloned code is more stable than non-cloned code, i.e. it is changed less often, it will require less maintenance efforts. The more stable cloned code is, the longer it will not have been changed, so the stability can be estimated through the code's age. This paper presents a study on the average age of cloned code.For three large open source systems, the age of every line of source code is computed as the date of the last change in that line. In addition, every line is categorized whether it belongs to cloned code as detected by a clone detector. The study shows that on average, cloned code is older than non-cloned code. Moreover, if a file has cloned code, the average age of the cloned code of the file is lower than the average age of the non-cloned code in the same file. The results support the previous findings that cloned code is more stable than non-cloned code.

show abstract

Section: Related Workmentioning

confidence: 99%

Is cloned code older than non-cloned code?

Krinke

2011

Proceedings of the 5th International Workshop on Software Clones

View full text Add to dashboard Cite

show abstract

“…We process the results of the clone detection to identify clones that co-exist within the same revision. A similar processing step is done in the work by Barbour et al [4], [16]. 3) Building Clone Genealogies: We build clone genealogies following the same method as our previous work [2].…”

Section: B Processing Datamentioning

confidence: 99%

An empirical study on the fault-proneness of clone migration in clone genealogies

Xie

Khomh

Zou

et al. 2014

2014 Software Evolution Week - IEEE Conference on Software Maintenance, Reengineering, and Reverse Engineering (CSMR-WCRE)

Self Cite

View full text Add to dashboard Cite

Copy and paste activities create clone groups in software systems. The evolution of a clone group across the history of a software system is termed as clone genealogy. During the evolution of a clone group, developers may change the location of the code fragments in the clone group. The type of the clone group may also change (e.g., from Type-1 to Type-2). These two phenomena have been referred to as clone migration and clone mutation respectively. Previous studies have found that clone migration occur frequently in software systems, and suggested that clone migration can induce faults in a software system. In this paper, we examine how clone migration phenomena affect the risk for faults in clone segments, clone groups, and clone genealogies from three long-lived software systems JBOSS, APACHE-ANT, and ARGOUML. Results show that: (1) migrated clone segments, clone groups, and clone genealogies are not equally fault-prone; (2) when a clone mutation occurs during a clone migration, the risk for faults in the migrated clone is increased; (3) migrating a clone that was not changed for a longer period of time is risky.

show abstract

“…However, instead of finding the origination of a buggy code, we map the buggy code to some intermediate snapshot and analyze its properties at that point in time. Selim et al (2010) study the impact of clones on software defects. They find that the relative defect proneness of clones vary across different systems.…”

Section: Clones and Bugsmentioning

confidence: 99%

Clones: what is that smell?

2011

View full text Add to dashboard Cite

Clones are generally considered bad programming practice in software engineering folklore. They are identified as a bad smell (Fowler et al. 1999) and a major contributor to project maintenance difficulties. Clones inherently cause code bloat, thus increasing project size and maintenance costs. In this work, we try to validate the conventional wisdom empirically to see whether cloning makes code more defect prone. This paper analyses the relationship between cloning and defect proneness. For the four medium to large open source projects that we studied, we find that, first, the great majority of bugs are not significantly associated with clones. Second, we find that clones may be less defect prone than non-cloned code. Third, we find little evidence that clones with more copies are actually more error prone. Fourth, we find little evidence to support the claim that clone groups that span more than one file or directory are more defect prone than collocated clones. Finally, we find that developers do not need to put a disproportionately higher effort to fix clone dense bugs. Our findings do not support the claim that clones are really a "bad smell" (Fowler et al. 1999). Perhaps we can clone, and breathe easily, at the same time.

show abstract

Studying the Impact of Clones on Software Defects

Cited by 54 publications

References 14 publications

Is cloned code older than non-cloned code?

Is cloned code older than non-cloned code?

An empirical study on the fault-proneness of clone migration in clone genealogies

Clones: what is that smell?

Contact Info

Product

Resources

About