This chapter introduced clones as a form of logical redundancy and compared it with other notions of redundancy used in computer science. Based thereon, it defined the central terms and metrics employed in this thesis. Besides, the chapter introduced the companies that took part in industrial case studies that are presented in later chapters.
3 State of the Art
This chapter summarizes existing work in the research area of software cloning in support of the claims made in the thesis statement (cf., Section 1.1). More specifically, it summarizes work on the
impact of cloning on software engineering and on approaches for its assessment and control1.
The structure of this chapter reflects the organization of this thesis: Section 3.1 outlines work on the impact of cloning on program correctness. Section 3.2 outlines work on the extent of cloning in different software artifact types. Section 3.3 outlines existing clone detection approaches and argues why novel ones had to be developed. Section 3.4 outlines work on clone assessment and management. Finally, Section 3.5 outlines work on the limitations of clone detection.
Each section summarizes existing work, outlines open issues and points to the chapters in this thesis that contribute to their resolution.
3.1 Impact on Program Correctness
It is widely accepted that cloning can, in principle, impede maintenance through its induced increase in artifact size and necessity of multiple, consistent updates required for a single change in problem domain information. However, there is no consensus in the research community on how harmful cloning is in practice. A survey on the harmfulness of cloning by Hordijk et al. [93] concludes that “a direct link between duplication and changeability has not been proven yet, but not rejected either”. Consequently, a number of researchers have performed empirical studies to better understand the extent of the impact on maintenance efforts and, especially, on program correctness.
Clone Related Bugs Li et al. [157] present an approach to detect bugs based on inconsistent re- naming of identifiers between clones. Jiang, Su and Chiu [159] analyze different contexts of clones, such as missingif statements. Both papers report the successful discovery of bugs in released soft-
ware. In [4], [237], [216] and [7], individual cases of bugs or inconsistent bug fixes discovered by analysis of clone evolution are reported for open source software. These studies thus confirm cases where inconsistencies between clones indicated bugs, supporting the claim for negative impact of clones for program correctness.
1A comprehensive overview of software cloning research in general is beyond the scope of this thesis. Please refer to Koschke [140] and Roy and Cordy [201] for detailed surveys.
3 State of the Art
Clone Evolution Indication for the harmfulness of cloning for maintainability or correctness is given by several researchers. Lague et al. [149], report inconsistent evolution of a substantial amount of clones in an industrial telecommunication system. Monden et al. [178] report a higher revision number for files with clones than for files without in a 20 year old legacy system, possi- bly indicating lower maintainability. In [132, 133], Kim et al. report that many changes to code clones occur in a coupled fashion, indicating additional maintenance effort due to multiple change locations. Thummalapenta, Aversano Cerulo and Di Penta [4, 216] report that high proportions of bug fixes occur for clones that show late propagations, i. e., inconsistent changes that are later made consistent, indicating that cloning delayed the removal of bugs from the system, or that the incon- sistencies introduced bugs that were later repaired. Lozano and Wermelinger [163, 193] report that maintenance effort may increase when a method has clones.
In contrast, doubt that consequences of cloning are unambiguously harmful is raised by several recent research results. Krinke [147] reports that only half the clones in several open source systems evolved consistently and that only a small fraction of inconsistent clones becomes consistent again through later changes, potentially indicating a larger degree of independence of clones than hitherto believed. Geiger et al. [76] report that a relation between change couplings and code clones could, contrary to expectations, not be statistically verified. Lozano and Wermelinger [163] report that no systematic relationship between code cloning and changeability could be established. In [148], Krinke reports that in a set of open source systems, cloned code is more stable than non-cloned code and concludes that it thus cannot be assumed to require more maintenance costs in general.
Bettenburg et al. [20] analyzed the impact of inconsistent changes to clones on program correctness. Instead of analyzing individual changes, they analyzed only released software versions. Of the analyzed bugs in the two systems, only 1.3% and 2.3% were found to be due to inconsistent changes to code clones, indicating a small impact of cloning on program correctness. Rahman et al. [189] analyze relation between code cloning and bugs and report that, in the analyzed systems, cloned code contains less bugs than non-cloned code.
Due to the diversity of the results produced by the studies on clone evolution, it is hard to draw conclusions w.r.t. the harmfulness of cloning. This is emphasized by the results from Göde [83], who analyzes evolution of type-1 clones in 9 open source systems to validate findings from previous studies on clone evolution. He reports that the ratio of consistent and inconsistent changes to cloned code varies substantially between the analyzed systems, making conclusions difficult.
Cloning Patterns Through cloning patterns, Kapser and Godfrey [123] contrast motivation and impact of cloning as a design decision with alternative solutions. They report that cloning can be a justifiable or even beneficial development action in special situations, i. e., where severe language limitations or code ownership issues prohibit generic solutions. Notably however, while they argue that lack of, or problems associated with alternative solutions can make up for them, they emphasize that for all cloning patterns the negative impact of cloning still holds.
Summary The effect of cloning on maintainability and correctness is thus not clear. Further- more, the above listed publications suffer from one or more shortcomings that limit the transferabil- ity of the reported findings.
3.1 Impact on Program Correctness
Many studies employ clone detectors in their default configuration without adapting them to the analyzed systems or tasks [4,7,76,147,148,163,189]. As a consequence, no differentiation is made, e. g., between clone candidates in hand-maintained or generated code, although clone candidates in generated code are irrelevant for maintenance. The employed notion of “clone” is thus purely syntactic and task-related precision unclear. For example, for one of the analyzed systems, Krinke reports that more than half of the detected clones were in code generated by a parser generator [148]. However, they were not excluded from the study, thus diluting its conclusiveness w.r.t. to the impact of cloning.
Instead of manual inspection of the actual inconsistent clones to evaluate impact for mainte- nance and correctness, indirect measures are used [4, 76, 83, 147–149, 163, 178]. For example, change coupling, the ratio between consistent and inconsistent evolution of clones or code stability are analyzed, instead of actual maintenance efforts or faults. Indirect measures are inherently inaccurate and can easily lead to misleading results: unintentional differences and faults, e. g., while unknown to developers, exhibit the same evolution pattern as intentionally independent evolution and are thus prone to misclassification. Furthermore, inconsistencies that are faults that have not yet been discovered, or have been fixed in different ways, can incorrectly be classified as intentional independent evolution.
Apart from their inaccuracy, the interpretation of the indirect measures is disputable. This is apparent for the measure of code stability as an indicator for maintainability. One the one hand, higher stability of cloned versus non-cloned code, could be interpreted as an indicator for lower maintenance costs of cloned code, as, e. g., done by [148]; fewer changes could mean less costs. On the other hand, it can be interpreted as an indicator for lower maintainability— developers might shirk changing cloned code due to the increased effort—indicating higher overall maintenance costs! Support for the latter interpretation is, e. g., given by Glass [81], who reports more changes for more maintainable applications than for unmaintainable code, simply because development exploits the fact that changes are easier to make.
The analyzed systems are too small (20 kLOC) to be representative [132,133] or omit analysis of industrial software [4, 7, 76, 83, 132, 133, 147, 148, 163, 189].
The analyses specifically focus on faults introduced during creation [157,159] or evolution [7] of clones, inhibiting quantification of inconsistencies in general. Or, in the case of [20], only look at bugs in released software, thus ignoring efforts for testing, debugging and fixing of clone-related bugs introduced and fixed during development.
Additional empirical research outside these limitations is required to better understand the impact of cloning [140, 201]. In particular, the impact of cloning on program correctness is insufficiently understood.
ProblemIt is still not well understood,how strongly unawareness of cloning during maintenance affects program correctness. However, as this is the central motivation driving the development of
clone management tools, we consider this precarious.
Contribution Chapter 4 presents a large scale case study that studies the impact of unawareness
of cloning on program correctness. It employs developer rating of the actual inconsistent clones instead of indirect measures, the study objects are both open source and industrial systems, and
3 State of the Art
inconsistencies have been analyzed independently of their mode of creation. It does, hence, not suffer from the above mentioned shortcomings.