[andorov]

DRY needs to be balanced with SRP (Single Responsibility Principle). You can legitimately have two functions that are exactly the same but they should not be DRY'd up if they are actually serving different purposes.

The use cases will likely diverge in the future, and if the functions are DRY'd making changes will make introducing bugs from the calling code that you're not working on easy. Eventually the single function will likely have a lot of conditions in it, which is a red flag for this situation.

[ramesh31]

>You can legitimately have two functions that are exactly the same but they should not be DRY'd up if they are actually serving different purposes.

I use what I've come to call the "Rule of Three" here.

The first time, don't even consider any kind of abstraction. Just do the thing.

The second time, don't abstract yet. Repeat yourself, but do it in a way that will scale and make abstraction possible, while mentally noting how you might abstract it.

The third time, abstract it.

Adhering to this, the vast majority of code will never reach that third stage, thus taming the complexity beast.

[javajosh]

I do something similar, but not as precisely specified as this. But I like it.

It's similar to my own rule about when to add a tool. I wait until I'm doing something else and I feel the lack of that specific tool. The first time, it's on my radar. The second time, it's time to get the tool. If you get it on first impulse, you'll drown in tools (and won't give the tools you have a fair shake). If you wait too long, you'll acclimate to not using the proper tool.

[mewpmewp2]

I use the rule of "Annoyance". When I get annoyed by having to rewrite what already exists, I'll try to make it DRY, or when I have to fix things in multiple places many times.

I outsource a lot of decisions to that feeling, so I can focus on other things.

It's a matter of time anyway when it's really easy to ask ChatGPT to refactor everything into this perfect code.

[kitkat_new]

> Adhering to this, the vast majority of code will never reach that third stage, thus taming the complexity beast.

yeah, because you probably forgot about at least one of the other repetitions somewhere in the code

as a developer you should know if it makes sense or not

[evntdrvn]

I call it WET, “Write Everything Twice”. It’s catchy enough that people remember/follow it, esp with the antonym making it memorable :)

[getoffmycase]

Thanks for putting the process of what I did twice in the last two days into clear, coherent words and logic.

[pydry]

I usually phrase this as balancing against loose coupling.

I've had bad experiences with the single responsibility principle. It sounds kind of right, but in practice "responsibility" is too vague and often surprisingly hard to agree on what is e.g. one responsibility vs. three responsibilities.

By contrast, loose coupling is more objective and can (at least in theory) be measured.