Source-linked AI summary
The Vision of Software Clone Management: Past, Present, and Future
Chanchal K. Roy, Minhaz F. Zibran, Rainer Koschke
TL;DR
Code clones have both benefits and maintenance risks, while prior research emphasized detection and analysis more than integrated management. This paper surveys clone-management activities and literature to identify achievements and directions toward a versatile clone-management system. It concludes that filtering relevant findings, identifying harmful clones, selecting treatments, and understanding root causes remain major challenges.
Problem
Clone research has largely emphasized detection and analysis, while practical clone management beyond detection remains comparatively underdeveloped despite clones’ mixed effects on software maintenance.
Method
The paper presents a comprehensive survey based on systematic review of 353 publications and investigation of clone-management activities including tracking, documentation, evolution, annotation, and refactoring.
Results
The survey identifies achievements and research scopes across clone management, including persistent challenges in detector evaluation, clone documentation, tracking, and reengineering.
Takeaways & Limitations
Future work should move toward an integrated clone-management system by addressing relevant-finding selection, harmful-clone identification, treatment choice, and root-cause analysis.
Takeaways & Limitations
The survey focuses on source-code clones, while clone definitions remain vague and Type-4 clone detection remains an open problem.
Abstract
from arXiv · showhide
Duplicated code or code clones are a kind of code smell that have both positive and negative impacts on the development and maintenance of software systems. Software clone research in the past mostly focused on the detection and analysis of code clones, while research in recent years extends to the whole spectrum of clone management. In the last decade, three surveys appeared in the literature, which cover the detection, analysis, and evolutionary characteristics of code clones. This paper presents a comprehensive survey on the state of the art in clone management, with in-depth investigation of clone management activities (e.g., tracing, refactoring, cost-benefit analysis) beyond the detection and analysis. This is the first survey on clone management, where we point to the achievements so far, and reveal avenues for further research necessary towards an integrated clone management system. We believe that we have done a good job in surveying the area of clone management and that this work may serve as a kind of roadmap for future research in the area
I. INTRODUCTION AND MOTIVATION
Code clones arise through common reuse practices and can provide productivity and modularity benefits while also increasing maintenance risks. Because clones are both useful and difficult to eliminate, this paper surveys clone research with particular emphasis on management beyond detection and analysis.
- Clone reuse can save implementation time, avoid repeated mistakes, and support independent evolution of similar components.
- Clones can inflate systems, propagate faults, and require consistent changes across copies to avoid bugs or vulnerabilities.
- Cloning is sometimes unavoidable because of programming-language limitations or generated code that developers must modify.
- Reported clone proportions range from 5% to 50% of a software system, with 9%-17% commonly reported, but aggressive refactoring is not always appropriate.
- The survey reviews 353 publications over 20 years and examines detection, analysis, management, documentation, tracking, evolution, annotation, and refactoring.
- Clone research grew from an early focus on detection toward analysis and management, although management received relatively less attention and needs further study.
III. CLONE MANAGEMENT
Clone management covers activities for detecting, avoiding, tracking, analyzing, documenting, and removing clones, but clone definitions remain dependent on similarity criteria and task context. The field therefore needs task-oriented taxonomies and broader management research, while this paper focuses on source-code clones.
- Clone management encompasses detection, evolution tracking, refactoring, documentation, analysis, and visualization of code clones.
- Clone definitions vary with program representation, detection mechanisms, and parameter settings, preventing consensus on a precise universal definition.
- The common taxonomy distinguishes Type-1 through Type-4 clones by increasing differences in syntax, statements, and functional implementation.
- Task-specific similarity taxonomies are expected because a clone’s value depends on purposes such as bug fixing or refactoring.
- Clone research also addresses models, diagrams, requirements, domain entities, and spreadsheets, but this paper limits its scope to source-code clone management.
B. Clone Management Activities
Clone management extends beyond detection to documenting, tracking, analyzing, and supporting decisions about clones as code evolves. Detection methods range from text and tokens to syntax, dependencies, metrics, hashing, and lower-level representations, but usefulness and evaluation remain open challenges.
- Clone management begins with detection and documentation, then tracks changes, analyzes clone justification or removal opportunities, and can use visualization to support management.
- A typical clone management workflow composes these activities and surveys support for each activity across the state of the art.
- Detection techniques compare source text, tokens, syntax trees, program dependencies, metrics, hashes, or compiled lower-level representations to identify similar code.
- Clone-detector usefulness and evaluation remain open because reliable benchmarks are scarce, configuration choices confound comparisons, and large-scale detection is challenging.
V. INTEGRATED CLONE DETECTION
Integrated clone detection connects detection with development environments or version-control systems, but most existing tools provide limited management support beyond finding and displaying clones. IDE-based coverage also remains restricted, especially for Type-3 clones.
- Integrated tools connect clone detection with an IDE or version-control system to support proactive clone management during development.
- CloneBoard and CPC extend clipboard-based detection with clone tracking, while CPC provides a framework for future clone-management technology and both support linked editing.
- Most surveyed IDE-based tools detect or visualize clones without supporting broader management activities such as tracking, analysis, or removal.
- IDE-based support for Type-3 clones is limited, and the literature suggests user studies should precede development of more effective management tools.
VI. CLONE DOCUMENTATION
Clone documentation must preserve clone locations and relationships as code changes, yet existing representations are sensitive to evolution and lack a universally adequate interchange model. Reliable shared documentation is therefore central to both tracing and tool comparison.
- Line-and-column locations and abstract clone-region descriptors are vulnerable to code changes, while marker-based IDE tagging is proposed as a more adaptable option requiring further investigation.
- Reliable clone-location capture is necessary for comparing tools and tracing clones across subsequent software versions.
- A common clone-information model must balance genericity and efficiency, but existing formats such as RCF do not address all needs and broad data exchange remains limited.
VII. CLONE TRACKING
Clone tracking maintains clone information as evolving software changes, balancing detection overhead with the need to preserve accurate clone genealogies and support analysis. Existing visualization and genealogy approaches remain useful but face unresolved validity, scalability, and empirical-assessment challenges.
- Tracking evolving clones: Re-detection can be computationally expensive for large systems, making it unsuitable for proactive clone management.
- Tracking evolving clones: Incremental detection updates clone information only around modified code, avoiding the overhead of repeatedly analyzing an entire large system.JSync removes changed or deleted fragments, buckets newly added or modified fragments with LSH, and compares fragments within buckets to update clone groups.
- Genealogies and evolution: Clone genealogies map clone groups across software versions, but Type-3 genealogy extraction and grouping remain open methodological questions.Most existing approaches focus on Type-1 and Type-2 genealogies, while gCad is identified as the only separately released Type-3 extractor in the cited discussion.
- Genealogies and evolution: Inconsistent clone changes have been linked to program faults, while late propagation is reported as more risky than other clone genealogies.
- Open research needs: Evolution studies need larger-scale evidence and richer change measures because genealogy classifications can depend on thresholds, minor changes, and uncertain causal interpretations.The paper calls for measures of how many clones change, across how many versions, and by how much, alongside further empirical validation of visualization techniques.
IX. CLONE ANNOTATION
Clone annotation supports documenting deliberate decisions not to refactor particular clones, while reengineering techniques range from renaming support to generative abstractions. Evidence shows that language constraints and clone differences limit complete automated removal.
- Clone annotation: Clone annotation can record deliberate decisions to retain clones and share those decisions among programmers during management.
- Reengineering and refactoring: Generics removed 40% of 68% redundant code in the Java Buffer Library, but language constraints limited their applicability.
- Reengineering and refactoring: XVCL-based generative programming eliminated 68% of the original Java Buffer Library code by representing similar classes and methods in adaptable form.
- Supporting maintenance: Consistency tools such as CReN and JSync support clone maintenance by checking identifier renaming and tracking changes in cloned regions.
- Reengineering and refactoring: Type-3 clones remain difficult to refactor automatically because their differences require abstraction beyond simple renaming.
XI. ANALYSIS AND IDENTIFICATION OF POTENTIAL CLONES FOR REFACTORING
Identifying clones suitable for refactoring requires analyzing their properties and context, but detector outputs are voluminous and visualization support remains incomplete. Existing tools offer multiple views, while future work needs management-oriented and empirically assessed visualizations.
- Visualization for clone analysis: Visualization aids analysis of clone properties and context before reengineering or refactoring decisions are made.
- Visualization for clone analysis: Clone detectors often return large volumes of minimally contextualized clone-pair or clone-group data, making suitable visualization crucial for clone management.CCFinder produced 13,062 clone pairs for Apache httpd, illustrating the scale of the presentation problem.
- Existing tools: Existing tools provide complementary views, including scatter plots, metric graphs, stacked charts, filtering, and multiversion genealogy analysis.
- Visualization gaps: Current visualizations emphasize clone dispersion in file-system hierarchies, whereas inheritance-hierarchy views could better support clone removal and refactoring decisions.
- Visualization gaps: Clone-evolution visualizations lack sufficient empirical assessment, motivating use-case-specific studies and visualizations for large clone datasets.
B. Cost-benefit Analysis and Scheduling of Refactoring
Clone-refactoring scheduling has been modeled with effort estimation, optimization, ranking, and analytic cost approaches, but realistic cost-benefit analysis remains weakly grounded. The paper calls for empirical studies to identify the factors shaping clone costs and gains.
- Existing approaches: Existing work models clone-refactoring effort and scheduling through optimization, search-based ordering, association-rule ranking, and analytic cost models.
- Open limitations: Realistic clone cost models remain limited because the field knows too little about actual costs, risks, benefits, and the factors influencing them.
- Open limitations: Empirical field studies and experiments are needed to estimate clone costs and gains, although many variables may prevent precise models.
XII. ROOT CAUSES FOR CODE DUPLICATION
Code duplication arises from deliberate reuse, technical and human limitations, accidental repetition, and maintenance-oriented strategies; clone management therefore spans preventive, corrective, and compensatory responses.
- Development Strategy: Code clones arise from reuse strategies including copying and pasting, forking similar solutions, and porting software to new platforms.
- Maintenance Benefits: Clones may be introduced to reduce development risk and support similar functionality, including in frequently updated financial software.
- Underlying Limitations: Language limitations, difficult system comprehension, and short deadlines can lead developers to repeatedly adapt or reimplement existing solutions.
- Cloning By Accident: Accidental cloning can result from repeated API or library usage patterns and coincidentally repeated solutions by different developers.
- Clone Management Strategies: Clone management comprises corrective removal, preventive avoidance, and compensatory techniques for clones that remain for valid reasons.
- Clone Management Strategies: Because proactive treatment is not always feasible, versatile management should support both proactive and retroactive handling, including timely monitoring notifications.
XIV. DESIGN SPACE FOR A CLONE MANAGEMENT SYSTEM
A versatile clone management system should integrate with development workflows while accommodating centralized and decentralized architectures, but the best strategy for different circumstances remains unknown.
- Integration Design: Clone management tools should be integrated into development processes rather than operating only as stand-alone detectors used after development.
- Design-Space Evidence: Copy-paste-based tool studies have limited applicability because their findings may not extend to similarity-based clone detection.
- Architectural Alternatives: The design space includes architectural centrality, decentralized support through local IDEs, and centralized client-server integration with version control.
- Open Research Question: The field does not yet know which integration strategy works best under which circumstances, motivating comparative research.
B. Triggering Actors in Clone Management
Clone management may be initiated by developers or systems, scoped narrowly or broadly, and extended beyond source code to earlier software artifacts and development stages.
- Triggering Actors: Human-triggered management can be invoked after code changes or scheduled periodically, whereas system-triggered management responds to events such as saves or repository check-ins.
- Scope of Activity: Clone-focused activities address selected clones, while system-focused activities address broad collections across the code base or system portions.
- Triggering Challenges: System notifications must avoid false alarms, while human-triggered actions require accurate on-demand data and meaningful problem indicators.
- Earlier Artifacts: Detecting clones in requirements and design models can help prevent duplicated implementations and reconsider architectural choices before source-code duplication emerges.
- Scope and Timing: Clone management should cover all software artifacts and begin early, with existing studies spanning requirements, models, sequence diagrams, and spreadsheets.
XV. INDUSTRIAL ADOPTION OF CLONE MANAGEMENT
Industrial adoption remains limited despite growing interest and available tools, while the survey identifies integrated management, empirical validation, and broader automation as continuing needs.
- Adoption Barriers: Clone management is not yet widely adopted because integrated tool support may be unavailable and the practical importance of clones remains uncertain.
- Evidence Needs: Long-term industrial case studies are needed to demonstrate real problems, usable solutions, and benefits that may emerge only over extended periods.
- Signs of Adoption: Industrial momentum is emerging through Eclipse plug-ins, Microsoft Visual Studio support, other industrial attempts, and a Dagstuhl seminar.
- Survey Contribution: The survey extends prior clone research by synthesizing clone-management achievements and research scopes toward a versatile management system.
- Technical Gaps: Clone research still faces unclear clone definitions, limited Type-3 support, and an open problem in Type-4 detection.
- Research Agenda: Beyond detection, researchers still need better filtering, ranking, treatment selection, root-cause analysis, refactoring support, and cost-benefit analysis.