Content deleted Content added
m →See also: clean up / fix section header naming (WP:ASL) using AWB |
GreenC bot (talk | contribs) |
||
Line 54:
* Each instance creates a code duplicate, with all the problems discussed in prior sections, but with a much greater scope. Scores of duplications are common; hundreds are possible. Bug fixes, in particular, become very difficult and costly in such code.<ref>{{ cite web | url=http://www.jaxmag.com/itr/online_artikel/psecom,id,638,nodeid,147.html | title=The Benefits of Coding Standards | publisher=JAX Magazine | author=Nigel Cheshire and Richard Sharpe | accessdate=2008-12-15 }}</ref>
* Such code also suffers from significant readability issues, due to the difficulty of discerning exactly what differs between each repetition. This has a direct impact on the risks and costs of revising the code.
* The [[procedural programming]] model strongly discourages the copy-and-paste approach to repetitive tasks. Under a procedural model, a preferred approach to repetitive 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 repetitively 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.<ref>{{cite web|url=http://www.stanford.edu/class/cs106x/handouts/14-Decomposition.pdf |title=Stanford University, CS 106X ("Programming Abstractions") Course Handout: "Decomposition" |publisher=Stanford University |accessdate=2008-06-04 |deadurl=yes |archiveurl=https://web.archive.org/web/20080516005005/http://www.stanford.edu/class/cs106x/handouts/14-Decomposition.pdf |archivedate=May 16, 2008 }}</ref>
* The general [[rule of thumb]] applicable to this case is "[[don't repeat yourself]]".
| |||