Nils Göde

Incremental Clone Detection

Finding, understanding and managing software clones - passages of duplicated source code - is of large interest in research and practice. There is an abundance of techniques to detect clones. However, all these techniques are limited to a single revision of a program. When the code changes, the analysis must be run again from scratch even though only small parts may have changed. In this paper, we present an incremental clone detection algorithm, which detects clones based on the results of the previous revisions analysis. Moreover, it creates a mapping between clones of one revision to the next, supplying information about the addition and deletion of clones. Our empirical results demonstrate that the incremental technique requires considerably less time than a non-incremental approach if the changes do not exceed a certain fraction of the source code. An incremental analysis is useful for on-the-fly detection and evolutionary clone analysis. On-the-fly detection may be integrated in an IDE and allows to re-run clone detection immediately when a programmer saves his changes or even while he/she is typing. In evolutionary clone analysis, many revisions of a system need to be analyzed in order to understand how clones evolve.

Frequency and risks of changes to clones

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 systems 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.

Evolution of Type-1 Clones

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.

Clone Stability

Code clones are said to threaten the maintainability of a system -- especially when the system evolves and source code is changed. Whether clones truly increase maintenance effort can be analyzed by comparing the stability of cloned code to the stability of non-cloned code. A previous study found that cloned code is even more stable than non-cloned code and, thus, requiring less maintenance effort -- contrary to the frequently voiced assumption. In this paper, we describe our partial replication and extension of this study using a more detailed measurement and considering different parameters for clone detection. In general, we were able to validate the findings of the previous study. We furthermore explored possible reasons to gain a better understanding of the unintuitive results.

Studying clone evolution using incremental clone detection

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 versions 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

Clone removal: fact or fiction?

Despite ongoing research in the field of code duplication, clone research has not yet investigated when and how developers remove clones. We think knowing how developers select candidates for removal and what techniques they use to eliminate duplication is essential to provide efficient clone management tools. Our empirical results show a significant discrepancy between clones detected by a state-of-the-art clone detector and duplication removed by developers. We believe it is necessary to have a better understanding of how developers approach and remove duplication to improve clone detectors as well as clone refactoring tools.

Efficiently handling clone data: RCF and cyclone

Exchange and inspection of clone information is an essential building block of successful clone management. Until now, a variety of different formats and tools for handling clone data has evolved. This paper presents two of our tools, both of which work closely together. We introduce the Rich Clone Format, which we have developed to standardize and ease the exchange of clone data. Furthermore, we describe our tool cyclone, which fosters the multi-perspective analysis of clone information.

Feature-based detection of bugs in clones

Clones bear the risk of incomplete bugfixes when the bug is fixed in one code fragment but at least one of its copies is not changed and remains faulty. Although we find incompletely fixed clones in almost every system, it is usually time consuming to manually locate these clones inside the results of an ordinary clone detection tool. In this paper, we describe in how far certain features of clones can be used to automatically identify incomplete bugfixes. The results are relevant for developers to locate incomplete bugfixes-that is, defects still existing in the system-and for us as clone researchers to quickly find examples that motivate the use of clone management.

Quo vadis, clone management?

Although potential benefits are frequently mentioned in the literature, empirical evidence is missing to concretize the costs and benefits of clone management. Without precise estimation of the expected gain, clone management will hardly ever become a self-evident part of serious software development, as for example version control systems are. A study on clones in our own code showed a complex relationship between costs and benefits, which, in addition, differs between individual clones. We conclude that empirical evidence, that adheres the diversity of clones, is needed to support the adoption of clone management in practice.

Oops! . . . I changed it again

Duplicated passages of source code-clones-are a threat to software maintenance as modifying duplicated code causes additional change effort and bears the risk of incomplete propagation of changes to all copies. Although previous studies have investigated the consistency and threats of changing clones, changes have always been analyzed detached from another-not considering that individual clones may change more than once during their lifetime. In this paper we present our study on the patterns of consecutive changes to clones in real systems and discuss in how far they are suitable for identifying unwanted inconsistencies.