[ebiester]

My first heuristic is: If I change the code in block A, is it assured that I will need to change the code in block B?

My second heuristic is: Can I name the method I wish to de-duplicate in a way that is honest for all cases I wish to cover, yet explains its business purpose?

The more it deviates from these heuristics, the more likely I am to duplicate the code in object oriented programming.

[BurningFrog]

My slightly different heuristic:

If fact X changes, how many places in the code do we have to change it?

If the number is > 1, relying on humans to realize that will, on average, always fail. I know of two ways to fix that.

[1]: DRY it up.

[2]: Write a test asserting that all the places use the same value.

Sadly, most people rely on this:

[3]: We "just have to remember" to do these changes in all places, despite the fact that human memory is unreliable, and the future person working on this code isn't even in the room when we decided this.

Any time I hear a "we just have to remember" variation, either from coworkers or in my thoughts, an alarm goes off.

[dllthomas]

[2b] is to use the type system to make sure the places are consistent, the practicality of which depends significantly on both particular task and choice of technology.

[3b] is adding comments, which is better than relying purely on memory but can often be missed. I've locally improved on this a bit by including cross-references on the relevant lines, along with tooling such that the referents are automatically surfaced during code review.

[terrortrain]

I wish I saved the source, but I saw somewhere the term: "Don't repeat concepts"

While it doesn't spell out a word, I think it's much better advice than DRY, and better aligns with your heuristics.

[Jtsummers]

That's actually more or less how DRY is described in The Pragmatic Programmer (20th anniversary edition):

> Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

Further on:

> Dry is about the duplication of knowledge, of intent. It's about expressing the same thing in two different places, possibly in two totally different ways. [emphasis in original]

And the next paragraph:

> Here's the acid test: when some single facet of the code has to change, do you find yourself making that change in multiple places, and in multiple different formats? Do you have to change code and documentation, or a database schema and a structure that holds it, or...? If so, your code isn't DRY.

[AnimalMuppet]

Early in my career, a co-worker and I developed the habit, when a bug was fixed, of asking each other "Did you fix it everywhere?"

But that's the problem right there. Why is there more than one place to fix it?

(Now, sure, if you're using a function call wrong, you need to fix it everywhere you call that function, and it's fine that there are multiple such places. That's what functions are for. But if it's something like how a value is calculated... why is there more than one place that calculates the value?)

[chrisweekly]

Related tangent: "AHA" (Avoid Hasty Abstractions) is a decent counter to the over-application of DRY. IME, people reach for DRY too quickly, at the expense of other worthy but more subtle principles.

[vikingerik]

The opposite principle of DRY is WET. Write Everything Twice

[ryanbrunner]

I think the old "remove duplication the third time you write it" is bad advice as well, to be honest.

First off, it excuses some really egregious behaviour like copying entire large chunks of code representing an identical concept just because "I haven't copied it twice yet". I've seen an entire controller and all related views copied wholesale because it needed to be placed in another area of the app (with identical visual and functional requirements)

Secondly, if the code is only incidentally identical, even 3 times isn't enough to say that you should apply DRY. 3 independent concepts that happen to currently share implementation still shouldn't be deduplicated. I think a great example of this is the inherited resources gem in rails that implements a "standard" interpretation of controller actions - which works well at first until your controllers need to do something other than basic CRUD. The fact that say, an update action handles parameters and saving in the same way as some other update action may currently be true, but is not at all guaranteed to be true in the future, even if you have 100 update actions in your app.

[marcosdumay]

If you know what application you are writing, there is absolutely no reason to do WET. You should always know if some code repetition is real or accidental.

But we don't always know what application we are writing.

[isleyaardvark]

> I think the old "remove duplication the third time you write it" is bad advice as well, to be honest.

Same. “That’s just DRY with extra steps!”

[gfunk911]

Exactly. I find it helps to also state that it doesn't mean "Don't Repeat Characters"

[dllthomas]

I've pointed out in the past that if the characters you're deduplicating don't actually have the same meaning, you're just compressing your code; I've been trying to popularize labelling that kind of aggressive misapplication of DRY "Huffman coding".

[cogman10]

It's because you are using the wrong term that it's not caught on. Obviously this is run length coding or maybe LZ coding ;).

[marcosdumay]

On the other hand, if you keep repeating the same character sequence there is probably some structure on your code that you can also abstract away. You are not restricted to factoring business concepts.

[dllthomas]

There's clearly structure you can abstract away; doing so may be convenient, and that convenience may even make it a good idea. I contend, though, that if it does not represent a "piece of knowledge" that you're factoring out then you are dealing with concerns other than "DRY".

I do agree that a piece of knowledge may not be a business concept.

[piaste]

I use, and teach juniors basically the same rule as your first one.

I phrase it a little differently though: "if something happened in the future that required a change to function A, would the same requirement apply to function B as well?"

I think your second heuristic is valid but a little dangerous, because being good at naming functions is somewhat orthogonal to being good at maintaining code.

[ebiester]

From my perspective, naming functions well is a key component of maintainable code.

However, in this case, I use it is an extension of the question "is this the same concept?" if it looks like useFloorWaxOrDessertTopping, it's a good clue that you may have the same lines of code but they are certainly not the same concept.