"Maintain one source of truth" is exactly what I mean by "DRY".
The question I ask myself constantly is "if this had to change, in how many places would I have to change it?". If the number is not 1, I consider it a "bug in waiting".
This is fairly simple for data. For code it can be more complex, but it's really about that same question. Is some algorithm changes, will I have to change code in 2 places?
I've seen people mistakenly bundle together similar code in the name of DRY like OP says, and it's an unfortunate thing. I recommend asking "the question" if you're unsure!
The way I tie these together in phrasing it to teams is to ask yourself “Is this _necessarily_ the same or _coincidentally_ the same?”.
Code which is necessarily the same might be something like “how to calculate an invoice total”. If you need to calculate totals in multiple places, you can’t calculate different totals for the same invoice. Have a single source of truth for this.
Code which is coincidentally the same might be something like “well, to get an invoice total we add up all these prices multiplied by quantity… and this spreadsheet we’re importing has the product cost and a multiplier to reach a desired profit, so that’s the same dollar amount multiplied by a number again!”. Creating a single implementation for this will only cause pain.
Even if these things are the same _right now_, there’s nothing saying they must remain the same. And as they diverge, you are going to be either creating brittle franken-code that causes bugs in seemingly-unrelated parts of the application when you make (slow, tedious) changes, or you’re going to keep only the repeated logic as it evolves and you will make the code more and more generic until it provides no useful abstraction whatsoever.
Don’t repeat things that must be the same. Do repeat things that just happen to be the same _right now_.
> The way I tie these together in phrasing it to teams is to ask yourself “Is this _necessarily_ the same or _coincidentally_ the same?”.
I'm a hobbyist. One of my apps recently had the exact same five lines of code in two functions.
After some thinking I decided to leave it like that. Moving it into a third function seemed just additional work without no benefit.
My question was: if I had to change A, would I have to change B? The answer was: Perhaps, but not in all cases. And if I had to, the change would have me look at both functions anyway, so it is not that I could just forget to change B. And it would be unlikely it changes at all in the next 2 years.
I like the system you have in place for it. I feel like I've been doing the same thing subconsciously without realizing how to verbalize it when others make that kind of mistake in code reviews. There's a difference between two methods that look similar and therefore should "reuse" code versus two methods that are referring to the same requirement and where if anything about that requirement changes then both methods should change even if the methods themselves look nothing alike.
"Maintain one source of truth" is exactly what I mean by "DRY".
The question I ask myself constantly is "if this had to change, in how many places would I have to change it?". If the number is not 1, I consider it a "bug in waiting".
This is fairly simple for data. For code it can be more complex, but it's really about that same question. Is some algorithm changes, will I have to change code in 2 places?
I've seen people mistakenly bundle together similar code in the name of DRY like OP says, and it's an unfortunate thing. I recommend asking "the question" if you're unsure!