0018-9162/06/$20.00 © 2006 IEEE July 2006 31P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y

C O M P U T I N G P R A C T I C E S

Three Public Enemies:Cut, Copy, and Paste

Copy-paste might seem to make life easier, but itoften leads to inconsistencies. Giving users thefreedom to specify semantic relationships amongcopied objects can help rectify this “crime.”

M any software developers know the feeling of desperately debugging aprogram only to discover after a sleepless night that the error stemmedfrom copy-pasted code segments that had become inconsistent in sub-sequent editing. Even worse is the sinking feeling that many moresuch subtle errors are waiting to be discovered.

The problems arising from copied code are not new, and many researchers haveinvestigated how to automatically find copied code segments.1-4 An often recom-mended approach is to refactor the copied code—generalize the segments to ameaningful programming language abstraction, such as function, macro, or class,and replace the segment’s occurrences with references to that abstraction.5 However,refactoring is not always the method of choice6 and is obviously not a solution forother kinds of text editing, which suffer from the same copy-paste deficiencies.

Given the extensive use of copy-paste operations and their tendency to causeinconsistencies, there is clearly a pressing need to rethink current editor pro-grams. One solution is to replace cut, copy, and paste with operations that cor-respond directly to the intended semantics behind their use. With these operations,the user can specify semantic relationships among copied objects, and the editorprogram can use that information to help in the long-term support of those rela-tionships. It would thus avoid the inconsistencies that currently arise from the useof cut, copy, and paste.

USE SCENARIOSTo understand why cut, copy, and paste can produce errors, it helps to see

exactly why people use these operations. There are five typical scenarios, someof which can create inconsistencies:

Cut to delete. Although this is not what its creators intended as the cut func-tion—and most programs do indeed have a separate delete operation—it is nev-ertheless possible. However, such use does not lead to inconsistencies, so thisscenario is relatively harmless.

Cut and paste to move something. Again, there’s no potential for inconsis-tencies, since something is simply moving from one place to another.

Copy and paste to duplicate. The idea is to have exactly the same thing at sev-eral places. Typing variable names is a good example of this scenario. Software

Zoltán Ádám MannBudapest University ofTechnology and Economics

32 Computer

engineers learn to use more descriptive variable namesthan i, j, or k, so they might create a variable myAction-ListenerForTheUpperRightButton, which they mightneed to access a dozen times. A possible strategy is tocopy and paste the variable name.

Copy and paste to create a template. In this case, theaim is to have two similar instances. Continuing theexample in the previous scenario, suppose a softwareengineer has finished the code that handles myAction-ListenerForTheUpperRightButton, and now he wantsto do the same thing with myActionListenerFor-TheUpperLeftButton. To avoid going mad, he copy-pastes and modifies the code.

Copy and paste without a logicalconnection. In this case there is nological relationship between originaland replica. For example, when pro-gramming a Java class, a softwareengineer might start the declarationof several methods with public void.To save time, she might want to typethis string only once and copy-pasteit for the other methods, and changeit for those that are, say, public int.This example differs from the previous one on the pointof logical connection. In the previous case, the textcopies have a logical connection; here they do not. If the software engineer changes the code that handlesmyActionListenerForTheUpperRightButton, chancesare high that she will make analogous changes to theother copy. However, if she changes a method’s modi-fier from public to private, she won’t usually need tochange the modifier of the other methods in the sameclass. Consequently, this scenario is less harmful—textcopies need not be consistent, so there’s no chance ofinconsistency problems.

These five basic use scenarios also cover one more interesting scenario: cut and then several pastes,which is really a move operation followed by one or more copies.

WHY THINGS GO WRONGInconsistencies arise in the third and fourth use sce-

narios. The most frequent problem is that the userchanges some text copies but forgets to change the oth-ers. In the fourth use, forgetting to change the copiedtext can open another possibility for inconsistency.

This is especially problematic for large, long-livedtexts—manuals, specifications, books, and programcode, for example—that must be updated multiple timesduring their life. In such cases, the writer often no longerremembers what additional changes she must make totext to make it internally consistent, or the originalwriter has moved on and others have inherited the text.

At the root of these errors is a key restriction: The usercan’t specify the exact semantics of copying. In their pre-

sent form, cut, copy, and paste help users replicate text,but they don’t help with the task of making sure that thecopied instances remain consistent. What is the point ofhaving a computer if it can’t perform this kind of task?

TOWARD THE IDEAL PROGRAMThe ideal editor program would have two key fea-

tures. First, it would not use a clipboard. The clipboardis problematic because it offers only short-term supportfor copying text and does not let users specify the seman-tics behind the copy operations. Second, instead of thetraditional cut, copy, and paste operations, the ideal pro-

gram would provide four operationsthat correspond to the use scenariosjust described: move, copy-identical,copy-and-change, and copy-once.

The move operation is exactlywhat it implies: The user moves textcompletely from one place toanother with no other effect. Thus,the move operation does not lead toinconsistencies. This contrasts to thecurrently used combination of cutand paste, in which text remains on

a clipboard, thus enabling the user to paste the text inadditional locations, which can lead to inconsistencies.

The copy-identical operation corresponds to the thirduse scenario described earlier—copying to have exactlythe same thing at several places. But copy-identicalwould not put the burden of ensuring consistency on theuser. Instead, after a copy-identical operation, the editorprogram would guarantee that the copies remain iden-tical. That is, when the user employs the copy-identicaloperation, the program memorizes which pieces of thedocument must remain identical. When the user changesone copy, the program automatically updates the oth-ers. The program also tells the user how many othercopies it has changed and invites the user to look at theother copies and possibly break the stored relationships.

The copy-and-change operation addresses the fourthuse scenario—copy text and modify the new instance toobtain something similar, but not identical, to the orig-inal. The program isn’t as proactive in this case becauseit can’t know how to apply a change in the original tothe replica. However, it can memorize when the useremploys the copy-and-change operation and notify her when it is possible that a change could lead to inconsistencies.

As long as the replica remains unchanged after copy-ing, the program should mark it with a suitable visualreminder to the user that she wanted to change it. Whenthe user does change the replica, the program wouldremove the reminder. When the user later changes thereplica again, the program should make it possible tonavigate to the original and change it if the user sodesires, but it would not signal her that she must change

Forgetting to change the copied text

is especially problematic for large, long-lived

documents.

July 2006 33

the original. On the other hand, if a user changes theoriginal, the program should tell her which replicas shemight have to change as well. Again, the program shouldoffer the user the chance to investigate and potentiallybreak the stored relationships.

Finally, the copy-once operation addresses the fifthuse scenario—copy text and possibly change it withoutimplicitly wanting to define a logical relationshipbetween original and replica. This is similar to the nor-mal copy-paste, in which the user copies text but theprogram does not store any relation between the origi-nal and the replica and will not try to help the user avoidinconsistency problems. This operation is also suitablefor people who have grown up with copy and paste anddo not want to become familiar with new semantics, aswell as for those who become annoyed when comput-ers try to be more intelligent than their users.

In addition to these four operations, the programshould provide a way to mark text for the next opera-tion. In contrast to copying something to the clipboard,marking has no remaining side effects beyond the nextoperation. This is not possible with traditional copy-paste because there is no way to remove something fromthe clipboard.

An exampleTo illustrate how the operations might work, consider

a programmer who wants to create a Java class repre-senting a point in the plane. He might start with the codesegment in Figure 1a.

At this point, the time is ripe for the first copying, asin Figure 1b. The programmer created a copy of the def-inition of xCoordinate and changed the name of theattribute in the replica to yCoordinate. He used thecopy-and-change operation because there is a logicalconnection between the two lines (it is no accident thatthe definition of the two coordinates is similar), but ofcourse the two lines are not meant to be identical.

Now the programmer adds a get method for one ofthe attributes—using additional copy operations—as inFigure 1c. Notice that he used the copy-identical oper-ation for the return statement because the name of thereturned variable must be identical to the name in thedeclaration of that variable. On the other hand, hecopied the public modifier using copy-once because thereis no logical connection between the modifier of the classand the modifier of the get method. To reduce theamount of typing, he merely exploited the coincidencethat the two modifiers match.

Implementation issuesImplementing the copy-identical operation and the

associated automatic updating is not trivial. The usercan apply the copy-identical operation to text that con-tains or is contained in a block previously copied usingcopy-identical. Therefore the program must store two

relations between the copied blocks: which blocks itmust keep identical (an equivalence relation) and the is-part-of relation.

Implementing the copy-and-change operation is simi-lar because again the text in a copy-and-change operationcould contain or be part of another block copied usingcopy-and-change. Therefore, the block hierarchy isimportant in this case as well. The only difference is thatthe other stored relation—which block was copied fromwhich one—is not symmetric. In the copy-identical oper-ation, the operation’s direction did not matter becausethe aim was only to keep those blocks identical. However,in the copy-and-change operation, the roles of the orig-inal and the replica are slightly different.

Of course, the relations that the copy-identical andcopy-and-change operations define are not independent:For example, text copied using copy-identical can con-tain another block of text involved in a copy-and-changeoperation. Therefore, the program must take intoaccount all three relations—those induced by copy-identical and copy-and-change as well as the is-part-ofrelation.

The program must also store these relations persis-tently so that it can enforce them beyond single editingsessions. Typically, this means storing them in the filethat contains the document. Another possible strategy isto store the relations in an additional file to avoid pol-luting the actual file with this information. A source-code editor, for example, could employ this strategy,since source files must contain only program code.

copy-identical

public class Point{ private int xCoordinate;}(a)

public class Point{ private int xCoordinate; private int yCoordinate;}(b)

public class Point{ private int xCoordinate; private int yCoordinate;

public int getXCoordinate() { return xCoordinate; }}(c)

copy-and-change

copy-once

Figure 1. Copy operations used to create a Java class representing a point in the plane. (a) Original code, (b) firstcopy operation, and (c) additional copy operations.

34 Computer

Implementing the move and copy-once operationsdoes not pose similar challenges because the programdoes not have to offer any further support after movingor copying the given text, thus it does not have to recordthese operations.

To illustrate the persistently stored relations inducedby the copy operations, Figure 2 shows the relationsresulting from Figure 1. The edge representing the copy-identical operation has arrows on both ends, since copy-identical defines a symmetric relation. In contrast, theedge representing the copy-and-change operation pointsfrom the original to the replica, since copy-and-changedefines an asymmetric relation. The copy-once opera-tion does not appear in this representation because itdoes not affect document consistency.

Applying the relationsTo illustrate the benefits of the proposed program,

consider the scenario based on the previous example, in which the programmer later changes the definition private int xCoordinate to private int horizontal-Coordinate. The editor program would then make twosuggestions. The first would be to change the definitionof yCoordinate. Because the programmer had copied thechanged definition using copy-and-change to yield thedefinition of yCoordinate, the program would suggestthat this definition might also need changing. And indeed,the programmer will probably want to change it toverticalCoordinate.

The second suggestion would be to automaticallychange the getXCoordinate method to return horizontal-Coordinate. Because the programmer copied the blockxCoordinate using copy-identical to the return statementof the getXCoordinate method, the program would suggest automatically changing that line to returnhorizontalCoordinate, which is exactly what the pro-grammer would want.

A lthough most of the examples given here are fromthe programming domain, the proposed opera-tions are also suitable for copying objects such as

parts of a picture or an audio or video file or spread-sheet cells. The operations offer powerful possibilitiesfor defining semantic relations between object copiesand help ensure consistency as the document evolves.Of course, with more flexibility comes the need to morecarefully consider the best option, which implies aslightly longer learning curve, but these efforts are asmall price to pay for the relief of not having to worryabout inconsistent text copies. This is especially true forlong-lived documents.

Instead of resorting to a one-size-fits-all solution, oneapproach could be to use traditional copy-paste forshort-lived texts and the proposed operations for long-lived texts. But using mark, move, and copy-once givesthe user approximately the same functionality as tradi-tional cut, copy, and paste. The new concepts simplyscale better because of the additional copy-identical andcopy-and-change operations.

All this works well and is relatively easy to implementif the user employs only one editor program to edit andcopy objects within one document. All copying is in therealm of the editor program, which can thus support thelong-term maintenance of the defined relations. The edi-tor program might even provide the same support forcopying across document boundaries. For that, it wouldprobably store the interdocument relationships in a cen-tral database.

However, things rapidly become more complicatedwhen the user must rely on multiple editor programs.Several users might be editing the same document, eachwith a preferred editor, or users might need differentprograms to copy objects between different documenttypes, such as between a spreadsheet and a diagram.Administering semantic relations beyond programboundaries clearly requires a generic mechanism thatthe operating system must provide and that editor pro-grams would access through standardized interfaces. Inthis respect, the situation is similar to that of the clip-board: The operating system provides a means for doingcopy operations between programs. Designing such afacility for the proposed operations on the operating-system level is an important goal for future research. ■

Figure 2. Internal representation of the copy operations in Figure 1.The vertical lines correspond to the is-part-of relation betweenthe relevant blocks of text; the other edges represent the copy-identical and copy-and-change operations.

public int getXCoordinate(){ return xCoordinate;}

copy-and-change

private int yCoordinate;

xCoordinate; xCoordinate;

private int xCoordinate;

copy-identical

July 2006 35

References1. B.S. Baker, “A Program for Identifying Duplicated Code,”

Computing Science and Statistics, vol. 24, 1992, pp. 49-57.2. S. Ducasse, M. Rieger, and S. Demeyer, “A Language-Inde-

pendent Approach for Detecting Duplicated Code,” Proc. Int’lConf. Software Maintenance, IEEE Press, 1999, pp. 109-118.

3. T. Kamiya, S. Kusumoto, and K. Inoue, “CCFinder: A Multi-Linguistic Token-Based Code Clone Detection System forLarge-Scale Source Code,” IEEE Trans. Software Eng., vol.28, no. 6, 2002, pp. 654-670.

4. J. Mayrand, C. Leblanc, and E. Merlo, “Experiment on theAutomatic Detection of Function Clones in a Software Sys-tem Using Metrics,” Proc. Int’l Conf. Software Maintenance,IEEE Press, 1996, pp. 244-253.

5. M. Fowler et al., Refactoring: Improving the Design of Exist-ing Code, Addison-Wesley, 1999.

6. M. Kim et al., “An Ethnographic Study of Copy and PasteProgramming Practices in Object-Oriented Programming Lan-guages,” Proc. Int’l Symp. Empirical Software Engineering,IEEE CS Press, 2004, pp. 83-92.

Zoltán Ádám Mann is a doctoral student in computer sci-ence at Budapest University of Technology and Econom-ics. His research interests include software engineering andembedded system design. Mann received an MS in computerengineering from Budapest University of Technology andEconomics. He is a member of the IEEE. Contact him atzoltan.mann@cs.bme.hu.

www.computer.org/join/grades.htm

GIVE YOUR CAREER A BOOST ■ UPGRADE YOUR MEMBERSHIP

Advancing in the IEEE Computer Society can elevate your standing in the profession.

Application to Senior-grade membership recognizes

✔ ten years or more of professional expertise

Nomination to Fellow-grade membership recognizes

✔ exemplary accomplishments in computer engineering

REACH HIGHER