Cover photo created by Jazlyn Borkowski
"DRY" is an acronym introduced, seemingly universally, to software engineers early in their education. F...
For further actions, you may consider blocking this person and/or reporting abuse
That's DRY. No need for a different acronym just because some people misapply the original. You can go around talking about MOIST code, but your basically just describing proper application of DRY.
As I was taught it, Don't Repeat Yourself, but also Write Everything Twice because it takes at least three repetitions to make an abstractable pattern.
Indeed, no need to replace DRY in our day-to-day. Rather, MOIST is one tool to teach the true intent of DRY and dispel misconceptions. Of course there are different ways to teach that, but MOIST is a great comical option and one I may likely use.
Exactly, the pattern needs to be established.
Agreed. This is DRY with extra steps.
Refactoring should be viewed as a journey or an evolution. Avoid hasty abstractions.
I love the MOIST concept! My mental model for DRY has generally been that it applies to business logic, not code (though of course the two will coincide), but MOIST summarizes that idea in a much more catchy and general way.
I can't give you a cake, but here's a 🦄!
I agree that sometimes, flat, repetitive code is easier to maintain. A good exemple is tests : kentcdodds.com/blog/avoid-nesting-...
They are linear an repetitive by nature and trying to factor them too much will cause more headaches than anything when having them to evolve.
Part of CSS is like that, some constants or just things that "happen to be alike" but won't necessary exactly the same all the time.
Tests have different priorities - Tests Too DRY? Make Them DAMP!:
"Since tests don't have tests, it should be easy for humans to manually inspect them for correctness, even at the expense of greater code duplication. …which emphasizes readability over uniqueness"
and yet
"the DRY principle is still relevant in tests; for example, using a helper function for creating value objects can increase clarity by removing redundant details from the test body."
The challenge is to keep inappropriate coupling (resulting from overzealous DRY) out of tests because that can lead to fragile tests.
I also humbly submit DoRK code: Do not Repeat Knowledge.
But MOIST is good.
😁
The problem here is not with DRY, its with design patterns. Yes you eliminated duplication, but in the wrong way. You should rather use registry or something like service-location in order to convey the operation to be performed. Creating configuration files/objects to specify the process or procedure to be performed when a certain value is received. If you pass value A, then it finds the operation for value A, and so on. When you want additional functionality to happen in certain cases and not in others, you then employ another design pattern, perhaps event driven design, where you have a publisher that tells a system that a value was received, and in other areas of the application, it will apply its own side effects for said value. There are ways to reach DRY standards without sacrificing code quality. You just have to hunt for them and keep improving your own way of coding.
A rather click-batesque title, some assertions made about DRY being harmful (and I don't think the example proves or disproves those assertions), and then a "lets not stick to DRY!"
I mean, I applaud you for not wanting to stick to any extreme, because we shouldn't do that.
But I have to wonder, if we're being "MOIST" without valid reason, we're burning CPU cycles needlessly somewhere (either at build time, which is mildly annoying, or at runtime, which is rather concerning).
Maybe JS developers don't care about CPU cycles though? :)
If we're being DRY without valid reason, we're over optimising/engineering the solution, and burning time in SDLC, which is also concerning. If we're being WET without valid reason, the product probably never ships in the first place (unless any of us are making AAA game titles, in which case, they ship and the dev's keep enjoying typing).
PS, for WET, I prefer "We Enjoy Typing"
I totally agree!
Bad Title.
S in SOLID and DRY are the top concern for good coding.
TLDR: A function does something. If something else is needed that does the same thing, call the function.
WET = Write Everything Twice