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.
Krinke @cite_13 analysed five open-source systems and their clone genealogies for inconsistencies between clones. He found that half of the changes in the systems' history were inconsistent. Yet, inconsistent clones did evolve mostly independently which is an indication that they did not represent faults.
@cite_13
2067377566 2152075773 2399550884 2114056383
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. Although source code cloning (copy&paste programming) represents a significant threat to the maintainability of a software system, problems usually start to arise only when the system evolves. Most of the related research papers tackle the question of finding code clones in one particular version of the software only, leaving the dynamic behavior of the clones out of consideration. Eliminating these clones in large software systems often seems absolutely hopeless, as there might exist several thousands of them. Alternatively, tracking the evolution of individual clones can be used to identify those occurrences that could really cause problems in the future versions. In this paper we present an approach for mapping clones from one particular version of the software to another one, based on a similarity measure. This mapping is used to define conditions under which clones become suspicious (or "smelly") compared to their other occurrences. Accordingly, these conditions introduce the notion of dynamic clone smells. The usefulness of these smells is validated on the Mozilla Firefox internet browser, where the approach was able to find specific bugs that resulted from neglecting earlier copy&paste activities. 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 Clones - duplicated source fragments - are said to increase maintenance effort and to facilitate problems caused by inconsistent changes to identical parts. While this is certainly true for some clones and certainly not true for others, it is unclear how many clones are real threats to the system's quality and need to be taken care of. Our analysis of clone evolution in mature software projects shows that most clones are rarely changed and the number of unintentional inconsistent changes to clones is small. We thus have to carefully select the clones to be managed to avoid unnecessary effort managing clones with no risk potential.