Talk:Don't repeat yourself/Archive 1

Archive 1

Self-reference

The Examples section is an inappropriate self-reference that needs to be moved to the Wikipedia namespace. Aside from the obvious fact that the section is a discussion of Wikipedia itself, it also links to a template, which I don't think should ever be done. ~ Booya ^Bazooka 21:31, 26 June 2006 (UTC)

Good points. I do think there's some validity to including Wikipedia, as well as other well-known examples, as cases where people accept some violation of DRY in return for other benefits. Listing such examples could be a means to more fully explain DRY. But my lengthy example about the Ghanian soccer player is best moved to somewhere more internal to Wikipedia. And perhaps I could just replace Wikipedia with wikis in general, since the salient point is that DRY is somewhat sacrificed as an acceptable price for community involvement.

I'll move the specifics to my user page for now, and take a stab at being less self-referential. Can you suggest where in the Wikipedia namespace I might move that example? - Regards, PhilipR 21:58, 26 June 2006 (UTC)

DRY and wikis

I think there's not much value in the "Arguments against DRY" and "Notable examples of DRY violation" sections:

• the idea that DRY is somehow antithetical to wikis is IMHO wrong. Encyclopedias of all kinds include duplicate information, and Wikipedia is no exception. DRY is not always a good idea and is not always applicable, just like many other general design principles.

[That's precisely the point -- it may not always be applicable. If you want to change the tone to be more positive, fine, but that's not a reason to take that point out.- PhilipR]

• there's no necessary reason that one would "impose standards based on DRY compliance." DRY is a general principle, not a law that is usually codified and strictly enforced.

Neilc 17:56, 28 June 2006 (UTC)

I believe the DRY principle applies to the method in which a system is built, not to its presentation aspect. So, which a print encyclopedia may list the same information twice, this is not a DRY "violation" — the issue is how that data is edited, and becomes a problem when the information is stored twice in the backend. There is something wrong about saying that wikis are essentially non-DRY, but I see where the sentiment is coming from. ~ Booya ^Bazooka 20:58, 28 June 2006 (UTC)

Fair enough -- but again, that's an argument to improve my first cut, not take it out. I'm reverting my changes back in in the hopes that they'll spur someone to improve on them, not just remove them. - PhilipR 18:29, 29 June 2006 (UTC)

DRY within build and configuration management

While I agree traditional build systems (such as make) and cm's (such as rcs, cvs, sub-version, etc.) do not do DRY justice there has been some work on having a two tier review process that enables DRY to be enforced at the human level. Specifically I am thinking of model's like Aegis and it's sister build system Cook. Peter Miller's, the author of both, basic philosophy on both systems is project management should follow development methodology. Additionally in the case of Cook he advocates a DAG of the whole project before the build starts see Recursive Make Considered Harmful — Preceding unsigned comment added by Sarek1024 (talk • contribs) 23:42, 2 December 2006 (UTC)

More encyclopedic

This article needs more work to be more encyclopedic instead of trying to teach the DRY approach. I've added two essentially similar formulations from the PL research community; they are well-known within that community. Pcap ping 10:58, 25 August 2009 (UTC)

On second though, they were not quite the same. This article was, and still is, pretty poorly written, containing plenty of WP:OR, i.e. stuff not attributable to Thomas and Hunt, or published in relation to their work. I've marked it as such. Pcap ping 12:55, 25 August 2009 (UTC)

By the way, I oppose merging anymost of the articles listed in hatnote here. (as detailed above) They are not the same notions. Pcap ping 12:56, 25 August 2009 (UTC)

Configuration management

I'm not convinced the objection is valid.

When you tag or branch using SVN for instance, you still apply DRY because the information is kept as a single instance in the SVN repository with appropriate chanes for each version (could be 1.5 & 2.0). —Preceding unsigned comment added by 89.2.77.46 (talk) 02:33, 16 September 2007 (UTC)

Indeed SVN's implementation applies the DRY principle internally. But no one knows that. What the user sees externally is duplication, allowing (controlled) divergence. From the user perspective, branching is really just copy/paste but under control. Marchash (talk) 22:59, 1 November 2009 (UTC)

Irony

"In software engineering, Don't Repeat Yourself (DRY) or Duplication is Evil (DIE)"

I love the irony here. 89.139.41.3 (talk) 13:11, 1 October 2010 (UTC)

Someone posted it to Reddit. flarn2006 [u t c] time: 00:24, 28 June 2016 (UTC)

WET paragraph seems nonsensical/unhelpful to me?

"WET solutions are common in multi-tiered architectures where a developer may be tasked with, for example, adding a comment field on a form in a web application. The text string "comment" might be repeated in the label, the HTML tag, in a read function name, a private variable, database DDL, queries and so on. A DRY approach eliminates that redundancy by leveraging frameworks that reduce or eliminate all those edit tasks excepting the most important one, leaving the extensibility of adding new knowledge variables in one place." <-This is just crap signifying nothing. It could be removed, but the section would be one or two sentences.--162.72.141.104 (talk) 07:42, 9 October 2016 (UTC)

Merge proposal

Merge tag needs to be removed, DYI is here to stay

Every developer worth their salt is learning or has learned about DYI, we would be doing a disservice to the greater community by removing or merging this article. The tags for merging need to be removed, it would be daft to merge this article now. M4bwav (talk) 16:35, 3 December 2009 (UTC)

Once and only once

This should definitely be merged with Once and only once, but under which title? Is one term more official or widely-used? ~ Booya ^Bazooka 04:49, 30 June 2006 (UTC)

Good question. I had no idea, so I applied the generic merge template instead of mergeto or mergefrom. DRY is used in The Pragmatic Programmer, a fairly influential book, so all else being equal it gets my vote. OAOO seems to have many more Google hits (330k to 60k), which could mean nothing if it's used more often in a non-technical sense but could possibly be relevant. Cheers, PhilipR 04:47, 2 July 2006 (UTC)

Neither seems particularly widely used. I've merged them to here simply because this article was originally the longer of the two. If anyone disagrees with my choice, please feel free to move them. JulesH 21:06, 1 August 2006 (UTC)

My understanding of OaOO has always been that it's distinct from DRY, with the separation being one of domain - DRY is on the domain of "information" (variables) and OaOO is on the domain of "behavior" (methods), based on the c2.com article for OaOO in the external references for this article, hence my edit. Let me know if there are any problems with or objections to my revision - I'm not real familiar with WikiEtiquette. :) ike (talk) 18:13, 21 January 2008 (UTC)

Rule of three (programming)

I propose merging Rule of three (programming) into this article. As it is written in that article, I see that rule of 3 is just a variation of DRY. I propose creating a new section about Rule of three and adding the contents of Rule of three (programming) there, with the explanation that it is a small variant of the DRY principle. --Antonielly (talk) 12:49, 16 December 2008 (UTC)

I am against any merging described in the header of the article. I think these rules are subjects in their own right, and to merge them would reduce the amount of high quality information passed on to readers.M4bwav (talk) 16:50, 21 April 2009 (UTC)

Each one can become a major section of a single article. This way, the similarities and differences of those highly overlapping concepts could be made much more explicit to the interested reader, and text redundancy could at the same time be prevented. Do you think something along those lines could satisfy your concerns? --Antonielly (talk) 18:11, 21 April 2009 (UTC)

I strongly oppose merging. It was stated previously and independently, and it's rather obvious it's not the same. First of all, DRY does not say much if anything about refactoring. Off the top of my head, following DRY you should re-write the code if you have only two copies of a chunk of code, so it becomes "the rule of two." Thus, it's not the same philosophy; Martin Fowler's is more flexible. Pcap ping 13:10, 25 August 2009 (UTC)

Single choice principle

I propose merging the Single choice principle article into the Don't repeat yourself article. Reasons:

1) Single choice principle is a particular case of Don't repeat yourself;

2) it is unlikely that the Single choice principle article will grow much longer, given that it is not a widely adopted terminology.

I currently think that the best course of action is to turn Single choice principle into a section of Don't repeat yourself, and the original wikipage should become a redirect to the new section (so that the references to it, e.g. in the Eiffel (programming language) article, remain consistent).

Comments? --Antonielly (talk) 13:57, 2 January 2009 (UTC)

I am against any merging described in the header of the article. I think these rules are subjects in their own right, and to merge them would reduce the amount of high quality information passed on to readers. While some of these terms may appear to describe the same thing, they are actually describing different semi-overlapping concepts. To merge these articles as described, is going to confuse people about the nature of these sometimes different, sometimes similiar ideas. M4bwav (talk) 16:50, 21 April 2009 (UTC)

This should probably be merged. It's only stated in Bertrand's Meyer's book. No indication of more widespread notability. See [1]. Pcap ping 19:16, 25 August 2009 (UTC)

Copy and paste programming

I propose merging the Copy and paste programming article into the Don't repeat yourself article. By far the main reasons for duplication are Copy and paste programming and reinventing the wheel (see Not Invented Here). DRY, among other things, means "no" to most instances of Copy and paste programming (much like Structured programming, among other things, means "no" to most instances of use of goto).

Perhaps a good way to merge them would be to turn Copy and paste programming into a major, upper-level section of the Don't repeat yourself article. --Antonielly (talk) 22:37, 18 February 2009 (UTC)

Absolutely opposed. That article is long, and has good description of the issue, i.e. a particular style of coding that DRY forbids. Merging it here would lose that clarity. Further the article describes the implications of copy&pasted in some detail, which would be off-topic here. The are many other types of information duplication one can imagine, and they should not be merged here either. Some forms of information duplication done on purpose are quite useful, e.g. denormalization. Pcap ping 13:23, 25 August 2009 (UTC)

Absolutely opposed. A careful reading of the "Copy and Paste" article shows that "don't repeat yourself" only applies to certain subtypes of the discussed material. The Plagarism and Legitimage Uses section have nothing to do with not repeating yourself. I feel that having all the relevant aspects of Copy and Paste programming here in one place is much preferred to trying to shoehorn them into a different article where they don't really belong. --Rnickel (talk) 17:48, 26 February 2010 (UTC)

Duplicate code

I propose merging the Duplicate code article into the Don't repeat yourself article. The discussion about the disadvantages of repeated code is basically the affirmation of the DRY principle. In the end, both articles talk about the same thing. Therefore, their contents should be merged. --Antonielly (talk) 22:37, 18 February 2009 (UTC)

Disagree. The articles should not be merged. Duplicate code is a very special case of Don't repeat yourself. A discussion of the specific software engineering issues involved would be completely out of place in a more general article. What is the policy on removing obviously inappropriate merge tags? Derek farn (talk) 00:30, 19 February 2009 (UTC)

As to the proper procedure to remove "merge" tags, they should be removed only after the discussion has ended. Clearly not the case now.

I fail to see why that merge tag would be inappropriate. The intended meaning of "Once and only once" and "Do not repeat yourself" is "Avoid replicating code (unless you have very good reason to do otherwise)". Duplicate code is in most cases a violation of the DRY principle. The articles Don't repeat yourself and Duplicate code talk about the same specific subject, therefore they should be merged in my opinion. If you think otherwise, please tell what would be the difference that justifies keeping both articles separate, and what would be the relationship between both articles then.

Anyway, the discussion here will probably be profitable and help us clarify things in order to improve the text of the article(s). If they talk about the same thing, a merge will create a better article in the end; if an essential difference is clarified, this will be made explicit in the text of both articles and the coverage of the subjects will be better in the end. This discussion has all the conditions to be a win-win situation. --Antonielly (talk) 12:45, 19 February 2009 (UTC)

I think that it would be beneficial to do a merge, but I think that all of the specifically programming related wikis should be merged and this left alone. This means merge duplicate code, copy and paste programming and rule of three. It would make the most sense to merge them all into Duplicate code, since it is the most general. Don't repeat yourself is more a philosophy (not necessarily related to computing) and the duplicate code article is about a practice.Michaelholman (talk) 06:46, 6 March 2009 (UTC)

Disagree, I think there is an argument that duplicate code is a subset of DRY, but the subjects are different enough that informed writers could attack the two related problems in different ways. M4bwav (talk) 16:55, 21 April 2009 (UTC)

I strongly oppose this too. Duplicate code describes a state of fact that happens in real-life software for a variety of reason, including, but not limited to Copy and paste programming (as described in the article). Just because the DRY philosophy prohibits it, it does not mean the article should be merged here. You're assume that DRY is the ultimate WP:TRUTH in software engineering, so all problems it claims to address must be merged with this ultimate solution. Very slanted WP:POV. Pcap ping 13:31, 25 August 2009 (UTC)

Yup, this is the correct argument. I'll remove the suggestion at the top. 130.92.9.55 (talk) 14:42, 20 February 2012 (UTC)

So, there are at lease 4 pages here on Wikipedia about not repeating yourself? Anybody else see the problem here? - Big Brother 1984 (talk) 17:25, 19 March 2012 (UTC)

Code reuse

There is a merge tag with Code reuse. I strongly disagree with that proposal. DRY and code reuse have a little overlap, but not nearly enough to define one as a subset of the other. DRY is a principle meaning that there should be one authoritative source of any piece of information in an application. Code reuse is about reusing code from one application in other applications. You can do this for DRY reasons (so there is one authoritative way to do things) or for other reasons, e.g. laziness. Note that in particular, the argument against code reuse makes no sense as an argument against DRY within an application. DRY in an application reduces code size and compilation time. It's only when code is reused across applications that it can cause code bloat with increased compilation times and highly coupled dependencies (as it tends to pull in more code than is needed for the immediate problem). Within an application, you are reusing existing data more so than code. Mdfst13 (talk) 22:05, 22 October 2016 (UTC)

Proposed merge with Dave Thomas (programmer)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

unnecessary article Light2021 (talk) 21:41, 4 July 2017 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

No one even participated. Seems like you are in hurry, closing all my Merge template as No Consensus, whereas many others Merge template exists for years. How it is no consensus? Explain?Light2021 (talk) 10:10, 6 August 2017 (UTC)

30 days have passed with no input from other users. Feel free to start a new discussion. I recommend adding a more comprehensive rationale that explains why the article is unnecessary. North America¹⁰⁰⁰ 10:17, 6 August 2017 (UTC)

I oppose such a merger. I see that Once and only once referred to above now redirects to the Abstraction article, it would be better if it pointed here instead. Once and only once and DRY are two names for the same thing, and both are popular names for an important concept in the agile community. It would be wrong to regard this as something that is only interesting in the context of an article on Dave Thomas. Martijn Meijering (talk) 12:06, 6 August 2017 (UTC)

Known Risks Suggestion

I propose adding a section to mention the possible pitfalls of overzealous DRY refactoring.

DRY code focuses on code reuse, but fails to address incorrect or accidental coupling. Elements of code that have very similar functionality but may change independent of one another are NOT candidates for removing duplication. Code should only be shared between modules with high cohesion.

Midas7g ^talk 20:00, 31 January 2018 (UTC)

References

Could this text be rewritten?

"leaving the extensibility of adding new knowledge variables in one place."

I have been a software engineer for 30 years, and I have no idea what that means. GeneCallahan (talk) 23:35, 2 December 2020 (UTC)