Hacker News Reader

Comment by dvh | Hacker News Reader

DRY code (usually with lot of IF blocks to handle special cases, or various oop lasagna) eventually turns into unmaintainable nightmare where every trivial new feature can take hours to implement and is very difficult, full of cussing, hair-pulling kind of programming where every 5 minutes you think "we need to rewrite everything from scratch, the system wasn't designed for this". Every change breaks million different unrelated things because of the complexity of extremely dry functions.

In WET code (write everything twice) everything looks primitive, as if it was written by complete newbie, and every change needs to be added at multiple places, but each change is trivial and time to finish is predictable. I would go as far as calling the code boring. The most difficult thing is to resist the temptation to remove the duplicity.

View on HN

I've seen code like this, what eventually happens is that all your 'copies' drift to be slightly different. Fixes get applied to some but not all of them, people copy from old code vs. new code, etc. And whenever you need to apply a fix you spend hours trying to figure out where each copy is, what it is supposed to be doing (since they're all different), and how the fix can be applied to it. You inevitably don't find them all and repeat the cycle.

This is also true. Some versions can be buggy and then a fix might not get everywhere. My favorite example is C code bases with a multitude of linked list implementations.

Like many things in software knowing when to do something and when not to do something can be hard. Premature DRY as the article mentions can lead to difficulty when eventually the use case diverges. Re-implementing everything every time everywhere is also silly. As mentioned in other places, I like the rule of 3, if you have 3 examples the point strongly a certain direction that's probably a good one to follow.

Which tool do you use to manage the copies of code segments, including possible modifications?

I imagine it's difficult to keep all of them in your head

It's just like any other code. But I think you might be onto something in terms of tooling help to manage that. I've had some ideas around this. I'll throw this out and if it turns into a billion dollar business please look me up for my share, treating code not as text files but as something deeper with metadata associated with it.

I think the key is more to ask yourself what it is you're abstracting away and whether the two things are actually doing the same thing. Just because the code is "shaped" in the same way (as in the article) doesn't mean it's actually conveying the same idea. If they're not really the same then the abstraction won't make sense and will just make things messier down the road.

It's the same thing as naming constants, but with code. If I have 3 `10` magic numbers in my code, I don't just immediately abstract them into a `const ten = 10` because they look the same, I abstract them into constants based on their actual purpose.

> In WET code (write everything twice) everything looks primitive, as if it was written by complete newbie, and every change needs to be added at multiple places, but each change is trivial and time to finish is predictable. I would go as far as calling the code boring. The most difficult thing is to resist the temptation to remove the duplicity.

This only scales so far. After some point, it's very easy to run into cases where you meant to change something everywhere but forgot/didn't know about others. Not to say everything should be so compartmentalized as to restrict change, but there is a balance to be had.

Yes, what actually happens is that many code changes are released half-baked because logic only got updated in 1 (or 13) of the 14 places that needed to be updated, and the cussing and hair pulling just starts later.

Tests, baby

Tests don't really help you when a newly discovered bug affects logic copied in ten places and you're only aware of two of them. You can add a regression test to the places that you update, but not the others. And then if there's another bug discovered in the duplicated code, a different subset of the copies might get changed and have tests added. Suddenly it looks like these different versions of the repeated logic are intended to be behaving differently for some unknown reason even though the divergence is purely accidental.

Which is why you need a balance between WET and DRY. DAMP = Don't Alter in Many Places.

I've never heard this one before, but I love it. Unfortunately we've also got "Don't Abstract Methods Prematurely" and "Descriptive And Meaningful Phrases".

Dumb Acronyms Must Pay?

Or, use a sufficiently well designed type-checking compiler, like GHC.

Why does everything need to be either DRY or WET? Like most things in life, there are no absolutes in programming, only tradeoffs.

Those may be good principles to think about when you are starting out with programming, but the key is to gain experience trying to solve problems in different ways.

Over time, you get better at making the right decision about whether duplicative code should be refactored or left alone.

To be fair, we can’t always make the “right” decision, but we can at least try to make the best decision we can based on the knowledge we have.

> but each change is trivial and time to finish is predictable

Until your ‘if’ soup reaches all the locations in your codebase, and now you have 10 different places with too many if statements instead of one. Likely all touching slightly different things, so you can’t simply copy from one file to the other any more.

Reply on news.ycombinator.com