SUMMARY Finding, understanding and managing software clones—passages of duplicated source code—is of large interest in research and practice. Analyzing the evolution of clones across multiple versions of a program adds value to both applications. Although there is an abundance of techniques to detect clones, current approaches are limited to a single version of a program. The current techniques to track clones utilize these single‐version approaches and map clones of consecutive versions retroactively. This causes an unnecessary overhead in runtime and may lead to an incorrect mapping due to ambiguity. In this paper, we present an incremental clone detection algorithm, which detects clones based on the results of the previous version's analysis. It creates a mapping between clones of consecutive versions along with the detection. We evaluated our incremental approach regarding its advantage in runtime as well as the usefulness of the mapping for studies on the clone evolution. Copyright © 2010 John Wiley & Sons, Ltd.

SUMMARY Code clones are said to threaten the maintainability of a system—especially when the system evolves and source code is changed. Whether clones increase maintenance effort can be analyzed by comparing the stability of cloned code with the stability of non‐cloned code. A previous study found that cloned code is even more stable than non‐cloned code and, thus, may require less maintenance effort—contrary to the frequently voiced assumption. In this paper, we partially replicate this study using a more fine‐grained measurement. We furthermore extend the study to subject systems from academia and industry and evaluate the effect of different clone detection parameters on clone stability and how the stability changes over time. In general, we were able to confirm the findings of the previous study. Nevertheless, our results also show that clone stability varies depending on the clones' characteristics, the corresponding project environment, and over time. Copyright © 2012 John Wiley & Sons, Ltd.

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.

It is useful to study the evolution of code clones to better understand the nature, effects, and reasons of cloning. There are different approaches that investigate multiple versions of a program and detect patterns in the evolution of clones. The shortcomings of these methods are that they require significant computational effort, are limited to detecting predefined patterns and are mostly based on heuristics. This paper presents an approach that models clone evolution based on the source code changes that were made between consecutive program versions. Instead of relating clone classes by predefined patterns, the focus is on how individual cloned fragments evolve. The model has been used to analyze different aspects of type-1 clone evolution in nine open-source systems. The empirical results show that the ratio of clones decreased in the majority of the systems and cloned fragments survived more than a year on average. It was found that -- depending on the system -- either consistent or inconsistent changes to clone classes were more frequent. Overall, the peculiarity of clone evolution is significantly different for each system, making general conclusions difficult.