Hacker News Reader

Comment by BeetleB | Hacker News Reader

Predictably, another article that doesn't know what DRY is, leading to slaying of strawmen.

I believe DRY was coined in Programming Pearls, and probably none of the examples in the article are instances of DRY.

DRY is about knowledge/requirements, not similar code. It is about ensuring that a given requirement is not duplicated in multiple places in the code. It is not about similar looking code, which often involves differing requirements but just happen to be coded similarly. The latter leads to coupling if you unify it into one piece of code.

View on HN

I sort of agree with you. A better title/approach would have been "These aren't DRY, they're silly 'no common code' bigotry". I find the article resonates because I've seen all of these anti-patterns defended with "because DRY". I agree, it's not DRY; but so many people get stuck on the "no code duplication" part. I'm not sure if the "This isn't DRY" is the best fight or "Sometimes DRY is not the best".

My favourite block of "DRY" code was a method that had a triple nested loop (for all object A, for all objects A.B, for all objects B.C) with a bunch of flags (like 15 different bools, ints, dates and arrays) that changed the ORM filters for A, for A->B, for B->C, and then changed what operations were done on A, B, C. Basically, at the end, the only similarity was the foreach part. The comment on the block of code had "Keep this loop together for DRY", as if they knew this was going wrong but not sure why. It ended up being 3 or 4 much simpler methods, based as you say, on requirements NOT code "shape".

> I'm not sure if the "This isn't DRY" is the best fight or "Sometimes DRY is not the best".

The problem is that when people believe this is DRY, they then tend to oppose the "real" DRY as well.

Likely we'll have to give another name to the "real" DRY principle. In general, I've always felt that catchy names/acronyms are a bad idea for anything (e.g. free software, open source, pro-life/choice, etc). Almost all of them end up being used in ways that were differ from the original intent.

I guess I have to agree, in the example I gave, I actually had to fight with members of the team because they were sure the new multiple function approach (one for user, company and analytics) wasn't "DRY" in their eyes.

Yes, thank you! Exactly what I was trying to express in another comment. And if you do it the right way, none of the problems with DRY usually brought up will be relevant. The whole notion of looking at code and trying to spot similarities to find abstractions is completely backwards.

I've referred to this in the past as "semantic duplication" (code that is the same by definition/requirement) vs. "syntactic duplication" (code that just happens to do the same thing today, but there is no requirement that requires both copies to remain the same).

The problem is that many/most junior through mid-level developers don’t share your definition of DRY.

Reply on news.ycombinator.com