I'm starting to think that DRY is overrated.

All good rules have exceptions to them.

Yeah, sometimes two slightly different things are just two slightly different things... But you'll still get that itch 😁

Do you really think DRY is overrated?

@anroven yeah, I think I really do.

maybe I think DRY is overrated

Feel free to test every best practice to see why it's a best practice.

Don't be afraid to question everything.

(But in the end you'll likely come back to embracing DRY. Though there is an exception to everything.)

@Root you see, when everything is reused, i.E, dry, things become tightly coupled. Components depend on each other so much that refactoring becomes a fucking pain.

It seems that the lower level you're at - the better DRY works out. The higher architecture level - the less it works [and the more it kills SOLID].

Well, RY then. It's a free country

@geronimo you mean WET, “write everything tangly”

@netikras It works better for smaller things. That's why it seems to work better for low-level: everything you do in lower level languages is smaller with less impact. Break apart your larger methods into smaller reusable ones, and your classes/sections/components/etc. will be less tightly bound.

Note, though, that this works less well with React due to React's nature, e.g. the dom elements everything adds. I'm assuming you're using React from your use of "component."

@Root I agree with you regarding divide-et-impera applied on methods. Yes, if we're talking about a single class scope, DRY works perfectly. Even if we're talking about a package/module scope - it's all right too [well in most of the cases]. But I've found DRY tends to make things much more difficult more often than not when we're in inter-package [inter-modular] layer. A sort-of-DRY works here if I build proper abstractions. But that's all.

Take Payments module for an instance. Payment can be implemented using different providers, e.g. PayPal, bank, card, cash, etc. They all do one thing: pay(Bill):Payment. But they do it very differently. If I build Bank payments there's pretty much nothing I can reuse from PayPal. And if I do find some repetitions and extract them to another method/module/wtv and reuse them, I'll tie a fat rope around my neck: it'll keep me warm and cozy until I have to move/change things.

But that's just my experience. The higher arch layer - the more WET.

@netikras I definitely agree with you there. Sometimes there really isn't any way of reusing your code. It's awful, but writing separate, similar implementations really is the cleanest and best approach. There's an exception to everything.

@ihatecomputers said it perfectly:

> Yeah, sometimes two slightly different things are just two slightly different things... But you'll still get that itch 😁

@netikras sometimes dry doesn’t have to mean 0 repetitions, just being smart about your methods. If they all send an Ajax request and get a response you can make some kind of function with a case statement that takes a paean, then makes the request based on the case statement,
Then does whatever next. You still repeat a lot of code in each case, but abstracting it further would just mean more conditions.

Code is poetry. Good poetry makes sense, and isn’t too repetitive or windy. Each stanza reads well enough by itself. But overall there is a theme. The poem is composed of words, reusable, well understood pieces of data. It may implement metaphors, hyperbole, understatement, analogy, and more or a combination. Just as your program may implement classes, functions, methods, variables, etc. code is used by machines but read by humans. Make it read well, and you’ll make it dry enough