Talk:Copy-and-paste programming
![]() | Computer science Start‑class Low‑importance | ||||||||||||||||
|
Expanded, organized, referenced
I have expanded this section's discussion of copy and paste programming by experienced programmers, and rather than having it as one continuous block of uninterrupted text, I've rearranged much of the text to create two distinct major sections. Also, I have added a number of references. I believe this article now qualifies for removal of the "no references" designation, as well as the "stub" designation. Rnickel (talk) 16:43, 5 June 2008 (UTC)
sweeping changes
While the Perl Design Patterns Books is a great resource, this article reproduced from it is not encyclopaedic. The article is very well written and well suited for a book on Perl Design Patterns, but it's next to useless as an encyclopaedia entry on a programming phenomenon. A fine example of cut and paste article writing!
I have replaced the article with a basic start on actually describing cut and paste programming, rather the in depth discussion of why it it's wrong to do it in Perl (which is what this article used to be).
???
oi! I like package Util. where else do you stick stalwarts like MakeStringBlankIfNull() and AddPI() ??
this page contains too many perl specific references. the code examples should be rewritten in pseudo-code and the perl package references should be dropped
Still wrong?
"However, adherents of object oriented methodologies claim that this form of programming is still wrong."
It may be wrong and that all code should be always completely different from something else, but most languages have certain things built into them that force you to use the same line of code as a previous situation, such as: public void actionPerformed(ActionEvent e)
You cannot avoid writing this line of code in Java in certain situations. 2 cents.
also known as: "bug & Paste" or "copy bug"
merge recommendation
Recommend Plug and Play modding content be merged into this article, provided adequate referencing is provided. Doesn't seem to be a distinctive enough practice for its own article Bwithh Join Up! See the World! 03:52, 11 February 2007 (UTC)
- The article was deleted via proposed deletion for lack of such adequate referencing. Rigadoun (talk) 19:35, 12 December 2007 (UTC)
I give up; what does "in conjecture with" mean?
That's in the first paragraph (the first two lines of the abstract). Better yet, what is it supposed to mean? —The preceding unsigned comment was added by 60.234.168.92 (talk) 01:13, 13 March 2007 (UTC).
I tried to remove bias
This article still seems strongly slanted against copying and pasting, ever, in programming. I've tried to remove some of that bias. Mathiastck 23:32, 23 May 2007 (UTC)
Neutrality
I agree that "It is a common mistake of the inexperienced or lazy programmer to duplicate code instead of writing a set of methods or objects", but unfortunately, this statement is obviously heavily biased and unattributed, and hence a violation of Wikipedia's "Neutral Point of View". My approach, when I did the reorganization of this article, was simply to dispassionately describe the problematic programming practices in the "Forms" section, and then to address the difficulties they create, with references, in the "Effects" section.
The fact that there has already been a change of "looping" to "set of methods or objects" is absolutely indicitive of the problem: there is no one single solution to bad programming. The general antidote is good decomposition, but what that will look like depends entirely on the programming methodology being used: procedural models will take a different approach than object oriented models for example. Rnickel (talk) 16:43, 22 July 2008 (UTC)
Loop unrolling etc
I reverted the good-faith edits made by 95.199.24.203 due to a number of problems with tone and sourcing:
- The tone was non-encyclopedic; it sounded conversational and read more like personal opinion.
- There were no sources for any of the statements; a number of them appeared to be original research.
- There were several grammatical errors.
I did preserve the mention of loop unrolling, since that seemed to me to be the most significant point raised. There could be further discussion of loop unrolling in the body of the article, although the statement that "a common practice to gain speed increase on modern computers" is egregiously untrue. In fact, manual loop unrolling has become all but extinct in the modern era as improvements in optimizer technology have removed the need for programmers to pursue these types of "speed hacks". --Rnickel (talk) 17:33, 30 July 2013 (UTC)