Hacker News Reader

Comment by dkdbejwi383 | Hacker News Reader

DRY is probably my least favourite programming meme. There are far too many overzealous juniors who learned it and have a bee in their bonnet about creating absurd abstractions around any two lines of code (or config) that have vague or imagined similarities, locking in all sorts of annoying indirection.

View on HN

My take is that all this WET/DRY wisdom makes people think about abstractions in the wrong way -- it makes us debate them in term of when, rather than what and why.

In my mind, the point of abstraction is to transform models such that we can build solutions in a way that is a better fit for the problems at hand. Reducing LOC and repetition is explicitly not the goal, sometimes a good abstraction may actually result in more lines of code (but more often it's less). So reducing LOC and repetition is commonly a happy byproduct, rather the reason we do it in the first place.

I see slightly more experienced programmers rebound from DRY to a point of having a pathological distaste for abstractions, and I find those codebases to be far more stressful to work in than ones which just happen to have a few bad abstractions.

I agree with rather having good or correct abstractions than saving LOC. However, a bad abstraction can give readers/devs the wrong idea about what is behind it, how it works or how it can be used and when to rely on it. Unreliable abstractions are terrible. Leaky abstractions are also terrible. Both introduce a lot of mental load overhead.

Some people choose “no abstraction” over “poor abstraction,” which I don’t understand. Working without any abstraction is the same as working with an infinitely leaky abstraction.

Yeah. A pervasive poor abstraction can be painful, but in my own experience most misguided abstractions tend to be somewhat superficial and easy to unwind. It does worry me to see so much rhetoric in the wider programming community encouraging people to avoid abstractions, because this is the kind of lesson that is easy to imprint on newcomers -- but I suspect the easiest way to get good at them, is to do them badly a few times.

Yes, that happens, but I've also had to take over a large iOS app written by a self-taught programmer who never learned DRY. They didn't factor out any shared code whatsoever. Any time they needed to do something that had already been done, they just bounced over to the other controller and copied the code over.

Of course, the copied code was often buggy, and they would only fix the instance in the controller where the bug was reported. When bugs were fixed it was pretty much random chance which version would be chosen to copy when needed again, so creating the right abstractions involved piecing together an entire phylogenetic tree of the code to decide which pieces were supposed to be the same and which were legitimately different.

Add a commit history that looked like "v1", "v2", "v3", and... yeah. We finally decided it would be cheaper to scrap the app and rewrite it from scratch.

So, yes, premature abstraction is a huge problem, but so is the opposite extreme, and after that experience I personally would choose overly-indirect code over the mess I inherited. It's easier to untangle a function that has too many callers than it is to find code that should have been shared after months of divergent evolution.

For me DRY is one of the most important principles for maintainable software. Imagine having to fix a bug at two independent places or having to add or change the same conceptual functionality at two different places (which you may not even be aware, because you don't remember you copied code somewhere else once) Totally unnecessary bugs guaranteed, and ready to be thrown away after some time, because a change will be harder than a rewrite.

It's enough pain when the effort is too big to avoid (e.g. Js frontend, Rust Backend) it.

Juniors will learn the difference between actual and imagined similarities at some time.

Funny enough this happened to me yesterday. I had to do a small change of code in a component and then when I pushed the code I got an error back. After searching for what was happening, it was actually a code I copied and named "Component2" two years ago when I was starting out. Today I would not have made it the way I did, but in my first month...

And thank god for github actions! :D

It is fundamental but it's in constant tension with other principles - e.g. cohesion and coupling.

I'm pretty sure all of the most fundamental principles of good code are in tension with each other.

Premature dryness is the real issue, not the principle itself. When you catch yourself fixing the same code in multiple methods again, it's a good time to stop and refactor.

DRY should really be "DRA" - don't repeat abstractions (which admittedly isn't as catchy).

The problem with DRY is when abstractions with currently identical implementations are given a single interface, even though they're logically distinct.

Then, when those distinct abstractions' implementations need to diverge, you've got a rats nest of references to manually pick through and separate out.

Or worse yet , the mistakenly-shared interface becomes parameterized, leading to a horrible mixing of requirements and concepts that may never be untangled if the original intent is lost to time.

Obviously DRY is great when you can consolidate multiple implementations that are actually a single abstraction, but it can really go off the rails if the motivation for the mantra isn't understood.

True, but then you also get times when somebody who should know better implements a "in current financial year w/ special cases" function 3 times.

Then your tester says it isn't correct in 2/3 places, you find out you've only updated the function in 1 place and either abstract those the other 2 cases out or update it in those 2 places aswell.

The worst part of DRY is that developers worrying about the amount of characters in a source file rather than readability, as if the compiler had a hard time reading those extra few kbs.

Totally agreed. I've tried explain exactly this issue in a talk [1], trying to find a useful synthesis between different paradigms like KISS, DRY and YAGNI.

[1] https://www.youtube.com/watch?v=0FIZn2trkoA&pp=ygUXbWljaGVsI...

I asked everyone's favorite chat AI to come up with a new buzzword using the letters from those.

The best was KINDergartener (uses all the letters). I would describe this as a programming paradigm for people who are new to the programming and real work and havn't found out that the getting shit done and shipping the code to users is the most important state for code to be in.

The trick is to understand this paradigms, why they came to be and what they want to archive and as much important when to not apply them.

Then program with the things you have learned in mind, instead of blindly following the some "paradigms rules", 'cause that's never ending well.

I made a DRY/YAGNI yin/yang sticker for my laptop a little while ago.

https://i.redd.it/16qm2a3m7m991.jpg

For best results, set your DRY dial to 8 or 9 out of 10. Settings higher than 9 result in premature or excessive abstraction.

But if you hate DRY so much, imagine a word where people set it to 1 or 2. I wouldn’t want to work in that code base.

Whatever you do, never turn it up to 11,

But what if you just need that extra bit of dryness and you're already at 10?

heck, sometimes even 7 is better than 9

Often the best way to DRY something if to let it sit in the sun a while where everyone can see it.

Seems whenever someone popularizes a rule of thumb, expressed in a catchy way, some newbies will take it as inviolable absolute law that everything else must be bent around, at any cost.

But remember you have to get WET (write everything thrice) before you get DRY.

I apologize for my dry humor.

I put it second behind "premature optimisation" which is used to justify never caring about performance at all (until it's too late and you can't do anything about it).

Actual premature optimisation is harmful for the same reason as premature abstraction. In both cases, improvements that come "for free" should be done without thinking, but one they start to impact readability, we should consider how beneficial those changes really are.

If you don't know what you are building, any action is premature.

My take is the opposite. DRY can be overused, but it is much easier to “undry”, than it is to consolidate duplicate code which should have been dry from the beginning. Sections of duplicate code tend to drift apart over time, making it more difficult to consolidate down the road.

DRY only paired with the rule of three (or more)

That, or the code block is sufficiently big and similar.

I remember a ex-colleague of mine who copied a 1000 line function, changed a parameter, and didn't see anything wrong with it.

Why do you have a 1000 line function in the first place? Sounds like an entire class of methods in a single structure.

The function contained 300 lines which he copied and pasted twice, because DRY and extracting into a function right away is dumb /s

Created by the same person. But the way he doubled his LoC contribution in this PR you could imagine why.

I had a coworker who did similar. It was essentially the entire frontend for an order application (back in the jQuery days), a few thousand lines. That was all copy/pasted, changed to deal with the case of when there are no orders (which only ever happens once since this was an in-house system) and those massive chunks were wrapped in an if/else.

I recently had a junior copy paste a 20 line code block rather than add an extra 'or' to the if statement.

Hey, rule of 3 ;)

Anyways, guidelines are just guidelines, regardless of what you come up with you can break it.

I’m not swayed by this rule of three. The experience I have is the reason I reach for a hammer immediately, instead of first trying three rocks to demonstrate that’s still a bad idea.

When I was younger, I really thought this was the be all end all, and probably committed more programmatic sins due to trying to achieve DRYness than anything else.

Often times it seems like we aim for DRY at the expense of simple, or idiomatic code. It also has a nasty habit of making code difficult to change since it leads to a lot of premature coupling, where someone sees a repetition and naively assumes that that needs to be eliminated, when it might literally be a naturally independent value.

It's definitely something that people overdo. But sometimes, especially with things like terraform, you have to struggle against the DSL to avoid having thousands of lines of repetitive code to do what could done in 100. I'll go quite far to avoid the situation I saw at at previous company, where they had 36k lines of trash to run a few data centers. Deploying a new data center was next to impossible.

DRY is priceless, and if your argument is to avoid DRY in very specific cases, state that specifically.

DRY, when used with functional, well named code is the number one thing keeping a codebase easy to read. There should be one way to achieve something well-defined like save/edit/delete an entity, check a file type, url encode a string, etc.

This ALWAYS leads to much easier code fixes AND much easier refactoring.

Reply on news.ycombinator.com