Inconsistent Changes to Code Clones

Nicolas Bettenburg

An Empirical Study on

at Release Level

Weyi ShangWalid IbrahimBram Adams Ying Zou

Ahmed E. Hassan

2

Code Clones: Recent Research in the Field

2

Code Clones: Recent Research in the Field

“Cloning Considered Harmful” Considered Harmful

Cory Kapser and Michael W. GodfreySoftware Architecture Group (SWAG)

David R. Cheriton School of Computer Science, University of Waterloo{cjkapser, migod}@uwaterloo.ca

Abstract

Current literature on the topic of duplicated (cloned)code in software systems often considers duplicationharmful to the system quality and the reasons commonlycited for duplicating code often have a negativeconnotation. While these positions are sometimescorrect, during our case studies we have found that this isnot universally true, and we have found several situationswhere code duplication seems to be a reasonable oreven beneficial design option. For example, a method ofintroducing experimental changes to core subsystems is toduplicate the subsystem and introduce changes there in akind of sandbox testbed. As features mature and becomestable within the experimental subsystem, they can thenbe introduced gradually into the stable code base. In thisway risk of introducing instabilities in the stable version isminimized. This paper describes several patterns of cloningthat we have encountered in our case studies and discussesthe advantages and disadvantages associated with usingthem.

1. Introduction

It is believed that most large software systems containa non-trivial amount of redundant code. Often referred toas code clones, these segments of code typically involve10–15% of the source code [24, 25]. Code clones canarise through a number of different activities. For example,intentional clones may be introduced through direct “copy-and-pasting” of code. Unintentional clones on the otherhand may be the manifestation of programming idiomsrelated to the language or libraries the developers are using.

In much of the literature on the topic [2, 7, 12, 21, 22,27, 28], cloning is considered harmful to the quality of thesource code. Code clones can cause additional maintenanceeffort. Changes to one segment of code may need tobe propagated to several others, incurring unnecessarymaintenance costs [15]. Locating and maintaining these

clones pose additional problems if they do not evolvesynchronously. With this in mind, methods for automaticrefactoring have been suggested [4, 7], and tools specificallyto aid developers in the manual refactoring of clones havealso been developed [19].

There is no doubt that code cloning is often an indicationof sloppy design and in such cases should be considered tobe a kind of development “bad smell”. However, we havefound that there are many instances where this is simply notthe case. For example, cloning may be used to introduceexperimental optimizations to core subsystems withoutnegatively effecting the stability of the main code. Thus,a variety of concerns such as stability, code ownership, anddesign clarity need to be considered before any refactoringis attempted; a manager should try to understand the reasonbehind the duplication before deciding what action (if any)to take. 1

This paper introduces eight cloning patterns that we haveuncovered during case studies on large software systems,some of which we reported in [23, 24, 25]. Thesepatterns present both good and bad motivations for cloning,and we discuss both the advantages and disadvantages ofthese patterns of cloning in terms of development andmaintenance. In some cases, we identify patterns of cloningthat we believe are beneficial to the quality of the system.From our observations we have found that refactoring maynot be the best solution in all patterns of cloning. Toolsneed to be developed to aid the synchronous maintenanceof clones within a software system, such as Linked Editingpresented by Toomim et al. [29].

This paper introduces the notion of categorizing highlevel patterns of cloning in a similar fashion to thecataloging of design patterns [14] or anti-patterns [8].There are several benefits that can be gained fromthis characterization of cloning. First, it provides aflexible framework on top of which we can documentour knowledge about how and why cloning occurs in

1A simple (but trivial) example is the title of this paper. Although thereis a kind of duplication in the wording, no ”refactoring” of the title wouldcarry the same connotations as the original statement.

Cloning asEngineering Tool

2

Code Clones: Recent Research in the Field

“Cloning Considered Harmful” Considered Harmful

Cory Kapser and Michael W. GodfreySoftware Architecture Group (SWAG)

David R. Cheriton School of Computer Science, University of Waterloo{cjkapser, migod}@uwaterloo.ca

Abstract

Current literature on the topic of duplicated (cloned)code in software systems often considers duplicationharmful to the system quality and the reasons commonlycited for duplicating code often have a negativeconnotation. While these positions are sometimescorrect, during our case studies we have found that this isnot universally true, and we have found several situationswhere code duplication seems to be a reasonable oreven beneficial design option. For example, a method ofintroducing experimental changes to core subsystems is toduplicate the subsystem and introduce changes there in akind of sandbox testbed. As features mature and becomestable within the experimental subsystem, they can thenbe introduced gradually into the stable code base. In thisway risk of introducing instabilities in the stable version isminimized. This paper describes several patterns of cloningthat we have encountered in our case studies and discussesthe advantages and disadvantages associated with usingthem.

1. Introduction

It is believed that most large software systems containa non-trivial amount of redundant code. Often referred toas code clones, these segments of code typically involve10–15% of the source code [24, 25]. Code clones canarise through a number of different activities. For example,intentional clones may be introduced through direct “copy-and-pasting” of code. Unintentional clones on the otherhand may be the manifestation of programming idiomsrelated to the language or libraries the developers are using.

In much of the literature on the topic [2, 7, 12, 21, 22,27, 28], cloning is considered harmful to the quality of thesource code. Code clones can cause additional maintenanceeffort. Changes to one segment of code may need tobe propagated to several others, incurring unnecessarymaintenance costs [15]. Locating and maintaining these

clones pose additional problems if they do not evolvesynchronously. With this in mind, methods for automaticrefactoring have been suggested [4, 7], and tools specificallyto aid developers in the manual refactoring of clones havealso been developed [19].

There is no doubt that code cloning is often an indicationof sloppy design and in such cases should be considered tobe a kind of development “bad smell”. However, we havefound that there are many instances where this is simply notthe case. For example, cloning may be used to introduceexperimental optimizations to core subsystems withoutnegatively effecting the stability of the main code. Thus,a variety of concerns such as stability, code ownership, anddesign clarity need to be considered before any refactoringis attempted; a manager should try to understand the reasonbehind the duplication before deciding what action (if any)to take. 1

This paper introduces eight cloning patterns that we haveuncovered during case studies on large software systems,some of which we reported in [23, 24, 25]. Thesepatterns present both good and bad motivations for cloning,and we discuss both the advantages and disadvantages ofthese patterns of cloning in terms of development andmaintenance. In some cases, we identify patterns of cloningthat we believe are beneficial to the quality of the system.From our observations we have found that refactoring maynot be the best solution in all patterns of cloning. Toolsneed to be developed to aid the synchronous maintenanceof clones within a software system, such as Linked Editingpresented by Toomim et al. [29].

This paper introduces the notion of categorizing highlevel patterns of cloning in a similar fashion to thecataloging of design patterns [14] or anti-patterns [8].There are several benefits that can be gained fromthis characterization of cloning. First, it provides aflexible framework on top of which we can documentour knowledge about how and why cloning occurs in

1A simple (but trivial) example is the title of this paper. Although thereis a kind of duplication in the wording, no ”refactoring” of the title wouldcarry the same connotations as the original statement.

Cloning asEngineering Tool

Do Code Clones Matter?

Elmar Juergens, Florian Deissenboeck, Benjamin Hummel, Stefan Wagner

Institut fur Informatik, Technische Universitat Munchen

Boltzmannstr. 3, 85748 Garching b. Munchen, Germany

{juergens,deissenb,hummelb,wagnerst}@in.tum.de

Abstract

Code cloning is not only assumed to inflate mainte-nance costs but also considered defect-prone as inconsistentchanges to code duplicates can lead to unexpected behavior.Consequently, the identification of duplicated code, clonedetection, has been a very active area of research in recentyears. Up to now, however, no substantial investigation ofthe consequences of code cloning on program correctnesshas been carried out. To remedy this shortcoming, this pa-per presents the results of a large-scale case study that wasundertaken to find out if inconsistent changes to cloned codecan indicate faults. For the analyzed commercial and opensource systems we not only found that inconsistent changesto clones are very frequent but also identified a significantnumber of faults induced by such changes. The clone de-tection tool used in the case study implements a novel algo-rithm for the detection of inconsistent clones. It is availableas open source to enable other researchers to use it as basisfor further investigations.

1. Clones & correctness

Research in software maintenance has shown that

many programs contain a significant amount of duplicated

(cloned) code. Such cloned code is considered harmful for

two reasons: (1) multiple, possibly unnecessary, duplicates

of code increase maintenance costs and, (2) inconsistent

changes to cloned code can create faults and, hence, lead

to incorrect program behavior [20, 29]. While clone detec-

tion has been a very active area of research in recent years,

up to now, there is no thorough understanding of the degree

of harmfulness of code cloning. In fact, some researchers

even started to doubt the harmfulness of cloning at all [17].

To shed light on the situation, we investigated the ef-

fects of code cloning on program correctness. It is impor-

tant to understand, that clones do not directly cause faults

but inconsistent changes to clones can lead to unexpected

program behavior. A particularly dangerous type of change

to cloned code is the inconsistent bug fix. If a fault was

found in cloned code but not fixed in all clone instances,

the system is likely to still exhibit the incorrect behavior.

To illustrate this, Fig. 1 shows an example, where a missing

null-check was retrofitted in only one clone instance.

This paper presents the results of a large-scale case study

that was undertaken to find out (1) if clones are changed in-

consistently, (2) if these inconsistencies are introduced in-

tentionally and, (3) if unintentional inconsistencies can rep-

resent faults. In this case study we analyzed three commer-

cial systems written in C#, one written in Cobol and one

open-source system written in Java. To conduct the study

we developed a novel detection algorithm that enables us

to detect inconsistent clones. We manually inspected about

900 clone groups to handle the inevitable false positives and

discussed each of the over 700 inconsistent clone groups

with the developers of the respective systems to determine

if the inconsistencies are intentional and if they represent

faults. Altogether, around 1800 individual clone group as-

sessments were manually performed in the course of the

case study. The study lead to the identification of 107 faults

that have been confirmed by the systems’ developers.

Research Problem Although most previous work agrees

that code cloning poses a problem for software mainte-

nance, “there is little information available concerning the

impacts of code clones on software quality” [29]. As the

consequences of code cloning on program correctness, in

particular, are not fully understood today, it remains unclear

how harmful code clones really are. We consider the ab-

sence of a thorough understanding of code cloning precari-

ous for software engineering research, education and prac-

tice.

Contribution The contribution of this paper is twofold.

First, we extend the existing empirical knowledge by a case

study that demonstrates that clones get changed inconsis-

tently and that such changes can represent faults. Second,

we present a novel suffix-tree based algorithm for the detec-

tion of inconsistent clones. In contrast to other algorithms

for the detection of inconsistent clones, our tool suite is

made available for other researchers as open source.

ICSE’09, May 16-24, 2009, Vancouver, Canada978-1-4244-3452-7/09/$25.00 ! 2009 IEEE 485

Inconsistent ClonesSingle Snapshots

2

Code Clones: Recent Research in the Field

“Cloning Considered Harmful” Considered Harmful

Cory Kapser and Michael W. GodfreySoftware Architecture Group (SWAG)

David R. Cheriton School of Computer Science, University of Waterloo{cjkapser, migod}@uwaterloo.ca

Abstract

Current literature on the topic of duplicated (cloned)code in software systems often considers duplicationharmful to the system quality and the reasons commonlycited for duplicating code often have a negativeconnotation. While these positions are sometimescorrect, during our case studies we have found that this isnot universally true, and we have found several situationswhere code duplication seems to be a reasonable oreven beneficial design option. For example, a method ofintroducing experimental changes to core subsystems is toduplicate the subsystem and introduce changes there in akind of sandbox testbed. As features mature and becomestable within the experimental subsystem, they can thenbe introduced gradually into the stable code base. In thisway risk of introducing instabilities in the stable version isminimized. This paper describes several patterns of cloningthat we have encountered in our case studies and discussesthe advantages and disadvantages associated with usingthem.

1. Introduction

It is believed that most large software systems containa non-trivial amount of redundant code. Often referred toas code clones, these segments of code typically involve10–15% of the source code [24, 25]. Code clones canarise through a number of different activities. For example,intentional clones may be introduced through direct “copy-and-pasting” of code. Unintentional clones on the otherhand may be the manifestation of programming idiomsrelated to the language or libraries the developers are using.

In much of the literature on the topic [2, 7, 12, 21, 22,27, 28], cloning is considered harmful to the quality of thesource code. Code clones can cause additional maintenanceeffort. Changes to one segment of code may need tobe propagated to several others, incurring unnecessarymaintenance costs [15]. Locating and maintaining these

clones pose additional problems if they do not evolvesynchronously. With this in mind, methods for automaticrefactoring have been suggested [4, 7], and tools specificallyto aid developers in the manual refactoring of clones havealso been developed [19].

There is no doubt that code cloning is often an indicationof sloppy design and in such cases should be considered tobe a kind of development “bad smell”. However, we havefound that there are many instances where this is simply notthe case. For example, cloning may be used to introduceexperimental optimizations to core subsystems withoutnegatively effecting the stability of the main code. Thus,a variety of concerns such as stability, code ownership, anddesign clarity need to be considered before any refactoringis attempted; a manager should try to understand the reasonbehind the duplication before deciding what action (if any)to take. 1

This paper introduces eight cloning patterns that we haveuncovered during case studies on large software systems,some of which we reported in [23, 24, 25]. Thesepatterns present both good and bad motivations for cloning,and we discuss both the advantages and disadvantages ofthese patterns of cloning in terms of development andmaintenance. In some cases, we identify patterns of cloningthat we believe are beneficial to the quality of the system.From our observations we have found that refactoring maynot be the best solution in all patterns of cloning. Toolsneed to be developed to aid the synchronous maintenanceof clones within a software system, such as Linked Editingpresented by Toomim et al. [29].

This paper introduces the notion of categorizing highlevel patterns of cloning in a similar fashion to thecataloging of design patterns [14] or anti-patterns [8].There are several benefits that can be gained fromthis characterization of cloning. First, it provides aflexible framework on top of which we can documentour knowledge about how and why cloning occurs in

1A simple (but trivial) example is the title of this paper. Although thereis a kind of duplication in the wording, no ”refactoring” of the title wouldcarry the same connotations as the original statement.

Cloning asEngineering Tool

Do Code Clones Matter?

Elmar Juergens, Florian Deissenboeck, Benjamin Hummel, Stefan Wagner

Institut fur Informatik, Technische Universitat Munchen

Boltzmannstr. 3, 85748 Garching b. Munchen, Germany

{juergens,deissenb,hummelb,wagnerst}@in.tum.de

Abstract

Code cloning is not only assumed to inflate mainte-nance costs but also considered defect-prone as inconsistentchanges to code duplicates can lead to unexpected behavior.Consequently, the identification of duplicated code, clonedetection, has been a very active area of research in recentyears. Up to now, however, no substantial investigation ofthe consequences of code cloning on program correctnesshas been carried out. To remedy this shortcoming, this pa-per presents the results of a large-scale case study that wasundertaken to find out if inconsistent changes to cloned codecan indicate faults. For the analyzed commercial and opensource systems we not only found that inconsistent changesto clones are very frequent but also identified a significantnumber of faults induced by such changes. The clone de-tection tool used in the case study implements a novel algo-rithm for the detection of inconsistent clones. It is availableas open source to enable other researchers to use it as basisfor further investigations.

1. Clones & correctness

Research in software maintenance has shown that

many programs contain a significant amount of duplicated

(cloned) code. Such cloned code is considered harmful for

two reasons: (1) multiple, possibly unnecessary, duplicates

of code increase maintenance costs and, (2) inconsistent

changes to cloned code can create faults and, hence, lead

to incorrect program behavior [20, 29]. While clone detec-

tion has been a very active area of research in recent years,

up to now, there is no thorough understanding of the degree

of harmfulness of code cloning. In fact, some researchers

even started to doubt the harmfulness of cloning at all [17].

To shed light on the situation, we investigated the ef-

fects of code cloning on program correctness. It is impor-

tant to understand, that clones do not directly cause faults

but inconsistent changes to clones can lead to unexpected

program behavior. A particularly dangerous type of change

to cloned code is the inconsistent bug fix. If a fault was

found in cloned code but not fixed in all clone instances,

the system is likely to still exhibit the incorrect behavior.

To illustrate this, Fig. 1 shows an example, where a missing

null-check was retrofitted in only one clone instance.

This paper presents the results of a large-scale case study

that was undertaken to find out (1) if clones are changed in-

consistently, (2) if these inconsistencies are introduced in-

tentionally and, (3) if unintentional inconsistencies can rep-

resent faults. In this case study we analyzed three commer-

cial systems written in C#, one written in Cobol and one

open-source system written in Java. To conduct the study

we developed a novel detection algorithm that enables us

to detect inconsistent clones. We manually inspected about

900 clone groups to handle the inevitable false positives and

discussed each of the over 700 inconsistent clone groups

with the developers of the respective systems to determine

if the inconsistencies are intentional and if they represent

faults. Altogether, around 1800 individual clone group as-

sessments were manually performed in the course of the

case study. The study lead to the identification of 107 faults

that have been confirmed by the systems’ developers.

Research Problem Although most previous work agrees

that code cloning poses a problem for software mainte-

nance, “there is little information available concerning the

impacts of code clones on software quality” [29]. As the

consequences of code cloning on program correctness, in

particular, are not fully understood today, it remains unclear

how harmful code clones really are. We consider the ab-

sence of a thorough understanding of code cloning precari-

ous for software engineering research, education and prac-

tice.

Contribution The contribution of this paper is twofold.

First, we extend the existing empirical knowledge by a case

study that demonstrates that clones get changed inconsis-

tently and that such changes can represent faults. Second,

we present a novel suffix-tree based algorithm for the detec-

tion of inconsistent clones. In contrast to other algorithms

for the detection of inconsistent clones, our tool suite is

made available for other researchers as open source.

ICSE’09, May 16-24, 2009, Vancouver, Canada978-1-4244-3452-7/09/$25.00 ! 2009 IEEE 485

Inconsistent ClonesSingle Snapshots

A Study of Consistent and Inconsistent Changes to Code Clones

Jens KrinkeFernUniversitat in Hagen, Germany

krinke@acm.org

Abstract

Code Cloning is regarded as a threat to software main-

tenance, because it is generally assumed that a change to

a code clone usually has to be applied to the other clones

of the clone group as well. However, there exists little

empirical data that supports this assumption. This paper

presents a study on the changes applied to code clones in

open source software systems based on the changes between

versions of the system. It is analyzed if changes to code

clones are consistent to all code clones of a clone group or

not. The results show that usually half of the changes to

code clone groups are inconsistent changes. Moreover, the

study observes that when there are inconsistent changes to

a code clone group in a near version, it is rarely the case

that there are additional changes in later versions such that

the code clone group then has only consistent changes.

1 Introduction

Duplicated code is common in all kind of software sys-tems. Although cut-copy-paste (-and-adapt) techniques areconsidered bad practice, every programmer uses them.

Since these practices involve both duplication and mod-ification, they are collectively called code cloning. Whilethe duplicated code is called a code clone. A clone group

consists of code clones that are clones of each other (some-times this is also called a clone class). During the softwaredevelopment cycle, code cloning is both easy and inexpen-sive (in both cost and money). However, this practice cancomplicate software maintenence in the following ways:

• Errors may have been duplicated (cloned) in parallelwith the cloned code.

• Modifications done to the original code must often beapplied to the cloned code as well.

Because of these problems, research has developed manyapproaches to detect cloned code [5, 6, 9, 12, 16–18, 20]. Inaddition, some empirical work done has attempted to check

whether or not the above mentioned problems are relevantin practice. Kim et al. [15] investigated the evolution ofcode clones and provided a classification for evolving codeclones. Their work already showed that during the evolutionof the code clones, consistent changes to the code clonesof a group are fewer than anticipated. Aversano et al. [4]did a similar study and they state “that the majority of cloneclasses is always maintained consistently.” Geiger et al. [10]studied the relation of code clone groups and change cou-plings (files which are committed at the same time, by thesame author, and with the same modification description),but could not find a (strong) relation. Therefore, this workwill present an empirical study that verifies the followinghypothesis:

During the evolution of a system, code clones of

a clone group are changed consistently.

Of course, a system may contain bugs where a changehas been applied to some code clones, but has been forgot-ten for other code clones of the clone group. For stablesystems it can be assumed that such bugs will be resolvedat a later time. This results in a second hypothesis:

During the evolution of a system, if code clones

of a clone group are not changed consistently, the

missing changes will appear in a later version.

This work will verify the two hypotheses by studying thechanges that are applied to code clones during 200 weeks ofevolution of five open source software systems. The contri-butions of this paper are:

• A large empirical study that examines the changes tocode clones in evolving systems. This study involvesboth a greater number and diversity of systems thanprevious empirical studies.

• The study will show that both hypotheses are not gen-erally valid for the five studied systems. In summary,clone groups are changed consistently in roughly halfof the time, invalidating the first hypothesis. The sec-ond hypothesis is only partially valid. This is because

c�2007 IEEE. To be published in the Proceedings of the 14th Working Conference on Reverse Engineering, 2007 in Vancouver, Canada. Personal use of thismaterial is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective worksfor resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.

Inconsistent ClonesWeekly Snapshots

3

Code Clones: Inconsistent Changes

“During the evolution of a system, code clones should be changed consistently to prevent bugs.”

3

Code Clones: Inconsistent Changes

“During the evolution of a system, code clones should be changed consistently to prevent bugs.”

Demonstrated to be true at a micro-level!

4

Revision Level vs. Release Level Analysis

Revisionsr2014 r2351r2209... ... ... r2682

4

Revision Level vs. Release Level Analysis

Revisionsr2014 r2351r2209... ... ... r2682

A

4

Revision Level vs. Release Level Analysis

Revisionsr2014 r2351r2209... ... ... r2682

AA

4

Revision Level vs. Release Level Analysis

Revisionsr2014 r2351r2209... ... ... r2682

AA

4

Revision Level vs. Release Level Analysis

Revisionsr2014 r2351r2209... ... ... r2682

AA

Bug

-Fix

ing

Exp

erim

enta

tio

n

Ref

acto

ring

4

Revision Level vs. Release Level Analysis

Revisionsr2014 r2351r2209... ... ... r2682

AA

Bug

-Fix

ing

Exp

erim

enta

tio

n

Ref

acto

ring

4

Revision Level vs. Release Level Analysis

Revisionsr2014 r2351r2209... ... ... r2682

AA

Inconsistent ChangesCode Clones

TimeA

mou

nt

Transient Effects

Bug

-Fix

ing

Exp

erim

enta

tio

n

Ref

acto

ring

4

Revision Level vs. Release Level Analysis

Releases2.1 2.32.2 2.4 3.0

Revisionsr2014 r2351r2209... ... ... r2682

AA

Inconsistent ChangesCode Clones

TimeA

mou

nt

Transient Effects

5

Study Design: Subject Systems

22 Releases over 1 year51 Days / release15k Lines of code

50 Releases over 4 years36 Days / release90k Lines of code

6

Study Design: Clone Detection & Tracking

Releases2.1 2.32.2 2.4 3.0

6

Study Design: Clone Detection & Tracking

Releases2.1 2.32.2 2.4 3.0

CloneReports

6

Study Design: Clone Detection & Tracking

Releases2.1 2.32.2 2.4 3.0

CloneReports

Clone Groups

6

Study Design: Clone Detection & Tracking

Releases2.1 2.32.2 2.4 3.0

CloneReports

Clone Groups

Genealogies

7

Study Design: Inconsistent Changes

2.1 2.32.2 2.4 3.0

Inconsistent Change Consistent Change

8

Research Questions

Q1 What are the characteristics of long-lived clone genealogies at release level?

Q2 What is the effect of inconsistent changes on code quality when measured at release level?

Q3 What type of cloning patterns do we observe at release level?

9

Research Questions

Q1 What are the characteristics of long-lived clone genealogies at release level?

Life-Time

Group Size

10

12

510

2050

Lifetime  of  Clone  GroupsNumber  of  Releases

Apache  MinajEdit

Number  of  Genealogies

10

12

510

2050

Lifetime  of  Clone  GroupsNumber  of  Releases

Apache  MinajEdit

Number  of  Genealogies

10

12

510

2050

Lifetime  of  Clone  GroupsNumber  of  Releases

Apache  MinajEdit

Number  of  Genealogies

10

12

510

2050

Lifetime  of  Clone  GroupsNumber  of  Releases

Apache  MinajEdit

Number  of  Genealogies

Long-lived clone groups

11

12

510

2050

100

200

Size  of  Clone  Groups

Number  of  Clones

Apache  MinajEdit

Number  of  Genealogies

11

12

510

2050

100

200

Size  of  Clone  Groups

Number  of  Clones

Apache  MinajEdit

Number  of  Genealogies

11

12

510

2050

100

200

Size  of  Clone  Groups

Number  of  Clones

Apache  MinajEdit

Number  of  Genealogies

Mostly small clone groups

12

Research Questions

Q2 What is the effect of inconsistent changes on code quality when measured at release level?

2.1 2.32.2

Inconsistent Change

Inspection

Reports

13

Research Question Q2

org.gjt.sp.jedit.jEdit.newView(View, Buffer){ ... // show tip of the day if(newView == viewsFirst) { // Don't show the welcome message if jEdit was started // with the -nosettings switch if(settingsDirectory != null && getBooleanProperty("firstTime")) new HelpViewer("jeditresource:/doc/welcome.html"); ...

org.gjt.sp.jedit.jEdit.newView(View, String){ ... // show tip of the day if(newView == viewsFirst) { // Don't show the welcome message if jEdit was started // with the -nosettings switch if(settingsDirectory != null && getBooleanProperty("firstTime")) new HelpViewer("jeditresource:/doc/welcome.html"); ...

4.0.2

jEdit

14

Research Question Q2

org.gjt.sp.jedit.jEdit.newView(View, Buffer){ ... // show tip of the day if(newView == viewsFirst) { // Don't show the welcome message if jEdit was started // with the -nosettings switch if(settingsDirectory != null && getBooleanProperty("firstTime")) new HelpViewer("jeditresource:/doc/welcome.html"); ...

org.gjt.sp.jedit.jEdit.newView(View, String){ ... // show tip of the day if(newView == viewsFirst) { // Don't show the welcome message if jEdit was started // with the -nosettings switch if(settingsDirectory != null && getBooleanProperty("firstTime")) new HelpViewer("jeditresource:/doc/welcome.html"); ...

4.0.2 4.0.3

jEdit

15

Research Question Q2

org.gjt.sp.jedit.jEdit.newView(View, Buffer){ ... // show tip of the day if(newView == viewsFirst) { // Don't show the welcome message if jEdit was started // with the -nosettings switch if(settingsDirectory != null && getBooleanProperty("firstTime")) new HelpViewer(); ...

org.gjt.sp.jedit.jEdit.newView(View, String){ ... // show tip of the day if(newView == viewsFirst) { // Don't show the welcome message if jEdit was started // with the -nosettings switch if(settingsDirectory != null && getBooleanProperty("firstTime")) new HelpViewer("jeditresource:/doc/welcome.html"); ...

4.0.3 4.0.4

jEdit

16

Research Question Q2

• 748 inconsistent changes flagged by our tool

•Manual inspection of reports and source code

•Only 7 inconsistent changes related to bugs

• Inconsistent changes seem carried out on purpose.

16

Research Question Q2

• 748 inconsistent changes flagged by our tool

•Manual inspection of reports and source code

•Only 7 inconsistent changes related to bugs

• Inconsistent changes seem carried out on purpose.

Only a fraction of inconsistent changes to

long-lived clones introduce bugs!

17

Research Questions

Q3 What type of cloning patterns do we observe at release level?

Releases2.1 2.32.2 2.4 3.0

Classification

CloneReports

ClonePatterns

18

Research Question Q3

!"#$%&'$

()*++(,-./$&'$#0#*1+$

%'$

"!)!123)#420$5'$

)2"6#(!32$!.0$+"2(#!6#42$

78'$

92):!;1$%'$

2<"2)#12.3$5'$

!"#$$%&'#()*+),+!)-.+!")*.$+%*+/0-%1+

!"#$%%&$

'()**'+,-.$/&$#0#)1*$

%%&$"!(!123(#420$

%&$

(2"5#'!32$!-0$*"2'#!5#42$

6/&$

72(8!91$%&$ 2:"2(#12-3$

;&$

!"#$$%&'#()*+),+!)-.+!")*.$+%*+/0#'1.+2%*#+

jEdit Mina

18

Research Question Q3

Replicate and Specialize46% - 68%

!"#$%&'$

()*++(,-./$&'$#0#*1+$

%'$

"!)!123)#420$5'$

)2"6#(!32$!.0$+"2(#!6#42$

78'$

92):!;1$%'$

2<"2)#12.3$5'$

!"#$$%&'#()*+),+!)-.+!")*.$+%*+/0-%1+

!"#$%%&$

'()**'+,-.$/&$#0#)1*$

%%&$"!(!123(#420$

%&$

(2"5#'!32$!-0$*"2'#!5#42$

6/&$

72(8!91$%&$ 2:"2(#12-3$

;&$

!"#$$%&'#()*+),+!)-.+!")*.$+%*+/0#'1.+2%*#+

jEdit Mina

18

Research Question Q3

Replicate and Specialize46% - 68%

API Usage22% - 23%

!"#$%&'$

()*++(,-./$&'$#0#*1+$

%'$

"!)!123)#420$5'$

)2"6#(!32$!.0$+"2(#!6#42$

78'$

92):!;1$%'$

2<"2)#12.3$5'$

!"#$$%&'#()*+),+!)-.+!")*.$+%*+/0-%1+

!"#$%%&$

'()**'+,-.$/&$#0#)1*$

%%&$"!(!123(#420$

%&$

(2"5#'!32$!-0$*"2'#!5#42$

6/&$

72(8!91$%&$ 2:"2(#12-3$

;&$

!"#$$%&'#()*+),+!)-.+!")*.$+%*+/0#'1.+2%*#+

jEdit Mina

19

Research Question Q3

!"#$%&'$

()*++(,-./$&'$#0#*1+$

%'$

"!)!123)#420$5'$

)2"6#(!32$!.0$+"2(#!6#42$

78'$

92):!;1$%'$

2<"2)#12.3$5'$

!"#$$%&'#()*+),+!)-.+!")*.$+%*+/0-%1+

!"#$%%&$

'()**'+,-.$/&$#0#)1*$

%%&$"!(!123(#420$

%&$

(2"5#'!32$!-0$*"2'#!5#42$

6/&$

72(8!91$%&$ 2:"2(#12-3$

;&$

!"#$$%&'#()*+),+!)-.+!")*.$+%*+/0#'1.+2%*#+

19

Research Question Q3

Inconsistent changes are carried out on purpose

because 70%-90% of the cloned code is meant to be changed separately!

!"#$%&'$

()*++(,-./$&'$#0#*1+$

%'$

"!)!123)#420$5'$

)2"6#(!32$!.0$+"2(#!6#42$

78'$

92):!;1$%'$

2<"2)#12.3$5'$

!"#$$%&'#()*+),+!)-.+!")*.$+%*+/0-%1+

!"#$%%&$

'()**'+,-.$/&$#0#)1*$

%%&$"!(!123(#420$

%&$

(2"5#'!32$!-0$*"2'#!5#42$

6/&$

72(8!91$%&$ 2:"2(#12-3$

;&$

!"#$$%&'#()*+),+!)-.+!")*.$+%*+/0#'1.+2%*#+

QUESTIONS?