Morning X rant. DRY.

Didn't you already cover this?

I like the original take they had in "The Pragmatic Developer" (which afaik was the first using the acronym). They define DRY as: > EVERY PIECE OF KNOWLEDGE MUST HAVE A SINGLE, UNAMBIGUOUS, AUTHORITATIVE REPRESENTATION WITHIN A SYSTEM The idea is not to write less code but rather to avoid having “business logic” (a term we now use to talk about that “knowledge”) defined in more than one place, which will eventually lead to bugs. Here's a thread with my thoughts on it I wrote some time ago:

I 100% agree with every thing said here One way to summarize dry is Dry is a heuristic not a first principle Use your judgement and you can break the dry heuristic. This is especially true if the code exists in separate contexts Like what Bob said about different modules

The problem is the cost of undoing the wrong consolidations. You should consildate things that change for the same reasons. But seperate those things that change for different reasons. Juniors not being able to spot the difference are the biggest cause of technical debt.

A very nice restatement of the single responsibility principle. Gather together, those things that change for the same reasons. Separate those things that change for different reasons.

The real insightful part of the video comes after 3:45 or so when he talks about two identical snippets in differrent modules driven by different forces, then you want to keep them separate fo decoupling purpose.

also, very very good point on identical snippets of code with different forces on them

Excellent breakdown of when to practice DRY and when the juice simply isn't worth the squeeze.

All code should be WET Write. Everything. Twice.

As a sometimes critic of DRY, I can't disagree with any of that. I think most of the hate for DRY is directed against people that apply it dogmatically, creating hundreds or thousands of little functions that becomes a confusing mess. There are real people out there who advocate for insane practices like "Methods should be no more than x (often single digit) lines." Aside from that, I absolutely love local functions. When you're able to use them, you gain the benefits of DRY with not much detriment, by virtue of locality and limited scope. Am I going to extract three lines used three times? Probably not, unless I can extract it into a local function.

"A little copying is better than a little dependency." ~> Go Proverbs,

that laugh at 1:13 alone was worth the price of admission

You said it would be fine as a macro and not a function. But it wasnt a function, it was actually a macro and Linus just called it a function.

Totally agree, especially the last point. I once trolled co-worker when he was talking about DRY. I asked him to repeat what he just told :D

Proud to call myself DRY Absolutist 🫳🏻🎤

this is so good . been struggling to articulate what i practice to the team, this nails it 💯 tq!

Many well-intentioned DRY neophytes get this wrong, annoying experienced devs. To DRY or not? First ask what the "destiny" of the observed code pattern is. Only when it's shared, should you apply DRY.

Loved the very last point you made. That insight gets lost even with “senior” engineers

he’s back

Linus was quite right. Kernel maintainers are extra sensitive to SRP violations in core code these days because they can affect stability across 20+ architectures.

Rules of thumb are nice, but no one has ever made anything beautiful by following them. Either the code is ugly or it's not. It would take Linux 100x the time defining all of the rules. Linus saying "that's shit" has 1000x the signal of any rule of thumb.

DaVinci was pretty good at thinking outside the box; but if you think he didn’t have disciplines and rules of thumb you are severely deluded.

you're reversing cause and effect

Two separate modules invoking the same method are bonded together. If this bond between the modules is unnecessary or does not makes sense, either from a technical or a business aspect, then it should be severed without second thought.

This is very accurate. The last part about different modules with what might appear as duplicate code evolving differently is an advanced observation that takes years for people to discover.

We are just some random PHP/JS web devs, however in my team the DRY principle is sacred. It is signed into law that any non-trivial line(s) of code shall not be duplicated. But yes, one can argue on what is considered (non-)trivial

This is very reasonable, I would also like to add that in the case of the Linux kernel, where hundreds of people come and go, it's very easy to end up continuously polluting the codebase with "helpers" so it makes sense to be a bit more strict about it

listening to this at 1:55am before I go to bed

1.) Afaik it was a macro, not a function 2.) I am perfectly OK with the idea of this macro/function as it improves readability, but the point is: If you have such functions you want them in a library with all similar functions (like 2x32bit to 64bit).

IME people often misuse DRY because they confuse mechanisms. They want to treat a function or object as a place to write an implementation that satisfies a general contract; changing its statements breaks clients that expected it to map specific inputs to specific outputs.

Absolutely agree — spotting some healthy repetition though. PS. I do like Linuses blunt style

@davepl1968

Perfect description for when not to use DRY. Agree 100%.

I want a rant of who you Win an email Bully fight, @FFmpeg or Torvalds Linus

lol macros yay

FWIW, out of a quick search: an online article entitled "Linus and the two youts - by Robert Graham - Cybersect" contains a link to the allegedly actual words of the case written by Linus.

It’s about contradiction. If it’s possible to only update some and then have a defect it’s better to remove the duplication. If there won’t be a defect by missing some or if the code is a norm that would require the work that is required to change a norm, then don’t.