Copy and paste programming

From Wikipedia, the free encyclopedia

This article does not cite any references or sources. (February 2007)
Please help improve this article by adding citations to reliable sources. Unverifiable material may be challenged and removed.

Copy and paste programming is an informal computer programming style that copies code from one program or procedure to another. It is often criticized as a bad practice or an anti-pattern. The term is in conjunction with a common activity in computing, copy and paste.

1 Forms of Copy And Paste Programming
2 Effects
- 2.1 Specific to Plagarized Code
- 2.2 Specific to Duplicated Code
3 References
4 See also
5 External links

[edit] Forms of Copy And Paste Programming

[edit] Plagarism

Copy and pasting is often done by inexperienced or student programmers, who find the act of writing code from scratch difficult and prefer to search for a pre-written solution or partial solution they can use as a basis for their own problem solving.^[1]

[edit] Duplication

[edit] As a way of applying library code

Copy and pasting is also done by experienced programmers, who often have their own libraries of well tested, ready-to-use code snippets and generic algorithms that are easily adapted to specific tasks.^[2]

[edit] As a way of branching code

Branching code is a normal part of large-team software development, allowing parallel development on both branches and hence, shorter development cycles. Classical branching has the following qualities:

Is managed by a high-quality version control system such as Subversion
Branches are re-merged once parallel development is completed.

Copy and paste is a less formal alternative to classical branching, often used when it is foreseen that the branches will diverge more and more over time, as when a new product is being spun off from an existing product.

[edit] As an approach to repetative tasks

Copy and pasting may also occur in code that performs a repetative task. Each repetition is copied from above and pasted in again, with minor modifications.

[edit] Deliberate Design Choice

Use of programming idioms and design patterns are distinct from copy and paste programming, as they are expected to be recalled from the programmer's mind, rather than retrieved from a code bank.

There is research aimed at "decriminalizing" cut and paste, known as the Subtext programming language. Note that under this model, cut and paste is the primary model of interaction and hence not an anti-pattern.

[edit] Effects

[edit] Specific to Plagarized Code

Inexperienced programmers who copy code often do not fully understand the pre-written code they are taking. As such, the problem arises more from their inexperience and lack of courage than from the act of copying and pasting, per se. The code often comes from disparate sources such as friends' or co-workers' code, Internet forums, code provided by the student's professors/TAs, or computer science textbooks. The result risks being a disjointed clash of styles, and may have superfluous code that tackles problems for which solutions are no longer required.
Bugs can also easily be introduced by assumptions and design choices made in the separate sources that no longer apply when placed in a new environment.
Such code may also, in effect, be unintentionally obfuscated, as the names of variables, classes, functions, etc, are normally left unchanged, even though their purpose may be completely different in the new context than it was in the original context.^[1]

[edit] Specific to Duplicated Code

[edit] As a way of applying library code

Being a form of code duplication, copy and paste programming has some intrinsic problems; such problems are exacerbated if the code doesn't preserve any semantic link between the source text and the copies. In this case, if changes are needed, time is wasted hunting for all the duplicate locations. (This can be partially mitigated if the original code and/or the copy are properly commented; however, even then the problem remains of making the same edits multiple times. Also, because code maintenance often omits updating the comments^[3], comments describing where to find remote pieces of code are notorious for going out-of-date.)
Adherents of object oriented methodologies further object to the "code library" use of copy and paste. Instead of making multiple mutated copies of a generic algorithm, an object oriented approach would abstract the algorithm into a reusable encapsulated class. The class is written flexibly, with full support of inheritance and overloading, so that all calling code can be interfaced to use this generic code directly, rather than mutating the original.^[4] As additional functionality is required, the library is extended (while retaining backward compatibility). This way, if the original algorithm has a bug to fix or can be improved, all software using it stands to benefit.

[edit] As a way of branching code

As a way of spinning-off a new product, copy and paste programming has some advantages. Because the new development initiative does not touch the code of the existing product:

There is no need to regression test the existing product, saving on QA time associated with the new product launch, and reducing time to market.
There is no risk of introduced bugs in the existing product, which might upset the installed user base.

The downsides are

If the new product does not diverge as much as anticipated from the existing product, you can wind up supporting two code bases (at twice the cost) for what is essentially one product. This can lead to expensive refactoring and manual merging down the line.
The duplicate code base doubles the time required to implement changes which may be desired across both products; this increases time-to-market for such changes, and may in fact wipe out any time gains achieved by branching the code in the first place.

As above, the alternative to a copy-and-paste approach would be an object-oriented approach:

Start by factoring out code to be shared by both products into libraries.
Use those libraries (rather than a second copy of the code base) as the foundation for development of the new product.
If an additional third, fourth, or fifth version of the product is envisaged down the line, this approach is far stronger, because the ready-made code libraries dramatically shorten the development life cycle for any additional products after the second.^[5]

[edit] As an approach to repetative tasks

For repetative tasks, the copy and paste approach often leads to large methods (a bad code smell).
The procedural programming model also discourages the copy-and-paste approach. Under a procedural model, a preferred approach to repetative tasks is to create a function or subroutine that performs a single pass through the task; this subroutine is then called by the parent routine, either repetatively or better yet, with some form of looping structure. Such code is termed "well decomposed", and is recommended as being easier to read and more readily extensible.^[6]

As reaction hereof the rule "don't repeat yourself" is cited.