Background: Code cloning - copying and reusing pieces of source code - is a common phenomenon in software development in practice. There have been several empirical studies on the effects of cloning, but there are contradictory results regarding the connection of cloning and faults. Objective: Our aim is to clarify the relationship between code clones and faults. In particular, we focus on inconsistent (or type-3) clones in this work. Method: We conducted a case study with TWT GmbH where we detected the code clones in three Java systems, set them into relation to information from issue tracking and version control and interviewed three key developers. Results: Of the type-3 clones, 17 contain faults. Developers modified most of the type-3 clones simultaneously and thereby fixed half of the faults in type-3 clones consistently. Type-2 clones with faults all evolved to fixed type-3 clones. Clone length is only weakly correlated with faultiness. Conclusion: There are indications that the developers in two cases have been aware of clones. It might be a reason for the weak relationship between type-3 clones and faults. Hence, it seems important to keep developers aware of clones, potentially with new tool support. Future studies need to investigate if the rate of faults in type-3 clones justifies using them as cues in defect detection.
Rahman, Bird and Devanbu @cite_0 analysed clone genealogies in four open-source projects. They found that the majority of reported defects in the projects were not associated with clones. They also found that clones are less defect-prone and faults in clones need a similar fix effort as in other code.
@cite_0
1973650376 2067377566 2399550884 2119887272
Clones are generally considered bad programming practice in software engineering folklore. They are identified as a bad smell ( 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" ( 1999). Perhaps we can clone, and breathe easily, at the same time. To study the impact of code clones on software quality, researchers typically carry out their studies based on fine-grained analysis of inconsistent changes at the revision level. As a result, they capture much of the chaotic and experimental nature inherent in any on-going software development process. Analyzing highly fluctuating and short-lived clones is likely to exaggerate the ill effects of inconsistent changes on the quality of the released software product, as perceived by the end user. To gain a broader perspective, we perform an empirical study on the effect of inconsistent changes on software quality at the release level. Based on a case study on three open source software systems, we observe that only 1.02 -4.00 of all clone genealogies introduce software defects at the release level, as opposed to the substantially higher percentages reported by previous studies at the revision level. Our findings suggest that clones do not have a significant impact on the post-release quality of the studied systems, and that the developers are able to effectively manage the evolution of cloned code. It is often claimed that duplicated code, also known as softwareclones, occurs frequently. Different researchers have reported clonerates in the range of 19 and 28 , in extreme cases even 59 forparticular systems. It is not clear, however, whether those systemsare just outliers. In this paper, we analyze about 7,800 open-source projects written inC or C++, summing up to 240 MSLOC, and measure their clone rates. Weuse statistical analysis to estimate the means of clone rates in open-source projects. Based on our findings, we could not confirm the high clone ratesreported in previous studies as expected averages. Except for smallprojects including a few copied and modified files, we found ratherlow clone rates compared to previous studies. For instance, if aminimal clone length of 100 tokens (roughly 16 LOC) is requested, wefound an average rate of duplicated type-2 clones of about 12 . Fortype-1 clones of this length, we found an average clone rate of only1 .However, our results show also that cloning is common. We identifiedonly 20 of the projects to have no type-2 clone of at least 100tokens. And 44 of the projects have at least one type-1 clone of atleast 100 tokens. Code cloning is not only assumed to inflate maintenance costs but also considered defect-prone as inconsistent changes to code duplicates can lead to unexpected behavior. Consequently, the identification of duplicated code, clone detection, has been a very active area of research in recent years. Up to now, however, no substantial investigation of the consequences of code cloning on program correctness has been carried out. To remedy this shortcoming, this paper presents the results of a large-scale case study that was undertaken to find out if inconsistent changes to cloned code can indicate faults. For the analyzed commercial and open source systems we not only found that inconsistent changes to clones are very frequent but also identified a significant number of faults induced by such changes. The clone detection tool used in the case study implements a novel algorithm for the detection of inconsistent clones. It is available as open source to enable other researchers to use it as basis for further investigations.