Copy And Paste

Code Copying: Good or Bad?

Another of the HiringPatterns:

Hook prospective programmers up to all kinds of sensors, nodes, etc., and then say the phrase "Copy and Paste".

The closer their reaction resembles death, the more likely their candidacy.

Also a time saver for those who are using a graphical user interface such as Windows, saving keystrokes and time. When combined with editing of the pasted object, such techniques can be productivity aids. BelieveItOrNot?, people other than programmers use this technique quite effectively every day. -- DonaldNoyes
With respect to productivity, I respectfully disagree insomuch as you forget: OnceAndOnlyOnce.

Note that OnceAndOnlyOnce imposes severe constraints and a controlled environment. It does not apply to such things as words, phrases, quotes, computer commands, a WikiWord (as opposed to the page to which it refers), words used in a language, iterative structures, etc. One must distinguish between definition and usage. But even definitions are modified by signatures.

No, it applies everywhere to every piece of PrimaryInformation, including variable, class, module, file, field names. When you put table name inside field name it's clear violation of once and only once because you should not duplicate table name inside any other name, or in general, any name inside any other name. I don't like naming style when people put variable types as part of variable names. If variable name contains class name or any other piece of information which introduces additional dependency on it, then it violates once and only once. -- AlekseyPavlichenko

Editing this page is a perfect example of the use of Copy and Paste, where the Page is copied in present form, is altered, and is saved in new form (pasted). Copying this page from the WikiServer at C2 and pasting it via the browser to the screen you are now reading. Rigid compliance to dogmas like OnceAndOnlyOnce would lead to unwanted situations. A bowl of soup served once and only once would not be very nourishing. If the Print command is used once and only once, there would not be the need for but one sheet of paper, one printer, one cartridge (ink or toner).

I disagree. When we print, we know that we can always reprint (at least with a well-designed system), which means that whatever we print we can throw into garbage at any time, which defines a printed piece of paper as SecondaryInformation and we don't need to apply OnceAndOnlyOnce here. At the same time, if somebody writes something on this piece of paper, we can not throw it away any more and it becomes PrimaryInformation and it makes it from hard to impossible to separate primary and secondary information using scanning and recognition. Only if we fail to extract primary information here do we have violation of once and only once.

Same logic applies to previous sample with a copy of WikiPage, but in that case it's easier to separate primary information from secondary.

-- AlekseyPavlichenko

In a society where duplication and multiplication can be a GoodThing, CopyAndPaste rules!
CopyAndPaste is the root of evil in programming. -- AhnKiYung

So don't do it! I however am not a programmer first and foremost, and for me the accomplishment of actual work, successful completion, and timeliness, depend greatly on the usage of the time saving method of copying and pasting.

antonym: GeneralizeOrGenerate

I don't like copy-and-paste, but the alternatives require a skill and experience level higher than many companies want to pay for. If staff's skills cannot handle decent factoring, then one is often stuck with copy-and-paste. One place I worked for got on my case for refactoring a situation with a duplication factor of 8. They had some developers in the past who had problems reading and modifying highly factored code (not mine) and it caused some major stirs. I reluctantly have to agree with them somewhat. There are several risks or downsides to refactoring:

As a developer, excessive copy-and-paste bothers me. But from a manager's or owner's perspective the cost of dealing with duplication may perhaps still be cheaper than the alternatives. The nature of office politics and limits on staffing flexibility play a role in this. I will generally factor my own code, but will not be militant about insisting on it with others.

An example experience was in trying to make a general HTML pull-down list utility. Variations kept popping up and adding them to the util turned it into a SpruceGoose?. Example features added over time:

Other developers looked at utils like this and gave me the evil eye. I had to agree that I deviated from KeepItSimpleStupid. The implementation was not the only problem; for the interface was large and awkward.

What I ended up doing was making one simple version and keeping the complex one around. Each site or project tends to have certain conventions that favor a few common sets of the features. Thus, I created an environment-tuned version for each project using old-fashioned copy-paste-and-modify. Those lists that deviated from the list util were simply hand-coded with strait HTML. (Related: HelpersInsteadOfWrappers)

The alternative to trying for The Ultimate Generic Thing is some amount of CopyAndPaste.

-- top

I just encountered a situation that is sticky. The data entry form and the read-only report version of the same form are very similar. Thus, I used the same programming code for both. However, there were many nitty-gritty differences that required addressing. For example, the input screen in some placed needed more explicit text to explain the input rules. Also, there were subtle formatting differences between the two because displayed text may take up a different amount of space than an input prompt.

I handled these by putting in a bunch of IF statements, such as IF INPUT_MODE THEN {...} ELSE {...}. This has made the code kind of cluttery. It is fine by me, but often others simply create the input form and then clone it (CopyAndPaste) and then modify the display-only version. It results in a lot of code duplication, but rids the mode-based IF statements and thus is cleaner. I could not make a strong case against the copy-and-paste version. The alternative is not a clear improvement.

I don't think sub-classing would work either because the differences are hard to partition in any clean, standard way. What is different for one form section may not be for another, which has its own idiosyncratic variations. The differences are as if somebody tossed darts in the dark. The polymorphism would be single-use. For this reason, a bunch of sub-classes would be worse than a bunch of IF statements in my opinion.


In general, OnceAndOnlyOnce requires a merging of the different contexts in which the information is used. The merge introduces an overhead. In the example above, the overhead are the IF statements added for the different contexts. Another solution would have been to have two different skeletons for the two pages and refer to the common parts through functions; also this solution would present considerable overhead. A refactoring is only good if the overhead of merging is limited. - ArnoutVandecappelle
If the code you are copying has a bug in it. You have just duplicated that bug and now forced that bug's fix to require a change in two places. BrianLeahy?
I understand copy and paste is 'evil', but I still feel that it is acceptable to save a few keystrokes with println statements and introducing new 'if-else' blocks, provided you are not introducing bugs or causing maintenance problems.
See also: CopyAndPasteProgramming, CloneAndModifyProgramming, ClassificationProblem

EditText of this page (last edited October 17, 2010) or FindPage with title or text search