Live data from Hacker News

Hang your code out to DRY

johan.hal.se

51–60 of 82 posts

Re: Hang your code out to DRY

#51

I really like WET (write everything twice). It also fits nicely with the rule of 3.

I really don't like either "the rule of 3" or WET because I think they take the focus off the part of DRY that matters. It shouldn't be about syntactic repetition, but (as originally stated) about repetition of pieces of knowledge.

The focus on syntax misleads in two ways. First, it sometimes motivates consolidation of things that are merely coincidentally syntactically similar (pushing back on this is most of where WET and Ro3 are useful, when they are), which makes it harder to update the code when one "piece of knowledge" needs updating but not the other(s). If you have 10 things that all happen to be identical today, but any of them might change independently in any direction, combining them isn't "more DRY".

Second, the same piece of knowledge may be repeated in different syntax. If your setup means you have to say "there's a button here" one way in HTML, another way in JS, and another way in CSS, then combining those would be "more DRY" even though no syntax repeats. This isn't to say that combining those (say through code generation?) would necessarily be better - DRY is a guideline to be balanced against other guidelines; but I do assert that it is a more useful guideline when we think in terms of duplicated knowledge than in terms of duplicated syntax.

Re: Hang your code out to DRY

#52

like many older developers, I have become less ideological about DRY over time, particularly as I have seen it motivate extremely abstract solutions that have proven difficult to understand and maintain i have coined the term "Locality of Behavior" (LoB) as a competing design principle to DRY (as well as Separation of Concerns, SoC) that advocates more inlining of (potentially repetitive) logic in the interest of cod…

Why does the "does it actually work" go down over time? I would expect to be the other way round: more experience, more chances your software "actually works", even if it's not following strict rules anymore.

The axis is labelled "relative importance". If you place non-zero value on readability, you must place less than 100% importance on "does it work".

Re: Hang your code out to DRY

#54

Earlier quoted context omitted.

Yeah; "favor composition over inheritance" remains good advice. "Classical" OO inheritance is brittle and often harmful.

Well, this is one of those "yes and no" situations. The biggest argument that I hear against OO, is that "someone may misuse or misunderstand it." I feel that this reflects the tech industry's obsession with hiring armies of relatively inexperienced developers, and then cycling through them, because we don't do what it takes to retain people. I like composition. I use it often. It is not a "one size fits all" solutio…

> I feel that this reflects the tech industry's obsession with hiring armies of relatively inexperienced developers, and then cycling through them, because we don't do what it takes to retain people.

That is true (and it won't change, so we need to behave like it won't...), but that is not the only reason.

An inheritance hierarchy in a large program that makes sense today might not make sense in a year or two. Refactoring it is hard. Refactoring a composition-based solution is easier.

Composition-based solutions are also easier to test: inject mocks. It's a lot easier to mock a compositional dependency than it is to mock behavior that's inherited from a parent class.

Given that composition is easier to maintain and test, and that it can achieve the same functionality as inheritance, I've pretty much stopped using inheritance. And I write Java 99% of the time.

Re: Hang your code out to DRY

#55

Earlier quoted context omitted.

The opposite principle of DRY is WET. Write Everything Twice

I think the old "remove duplication the third time you write it" is bad advice as well, to be honest. First off, it excuses some really egregious behaviour like copying entire large chunks of code representing an identical concept just because "I haven't copied it twice yet". I've seen an entire controller and all related views copied wholesale because it needed to be placed in another area of the app (with identical…

If you know what application you are writing, there is absolutely no reason to do WET. You should always know if some code repetition is real or accidental.

But we don't always know what application we are writing.

Re: Hang your code out to DRY

#56

Earlier quoted context omitted.

The opposite principle of DRY is WET. Write Everything Twice

I think the old "remove duplication the third time you write it" is bad advice as well, to be honest. First off, it excuses some really egregious behaviour like copying entire large chunks of code representing an identical concept just because "I haven't copied it twice yet". I've seen an entire controller and all related views copied wholesale because it needed to be placed in another area of the app (with identical…

> I think the old "remove duplication the third time you write it" is bad advice as well, to be honest.

Same. “That’s just DRY with extra steps!”

Re: Hang your code out to DRY

#57

Earlier quoted context omitted.

Well, this is one of those "yes and no" situations. The biggest argument that I hear against OO, is that "someone may misuse or misunderstand it." I feel that this reflects the tech industry's obsession with hiring armies of relatively inexperienced developers, and then cycling through them, because we don't do what it takes to retain people. I like composition. I use it often. It is not a "one size fits all" solutio…

> I feel that this reflects the tech industry's obsession with hiring armies of relatively inexperienced developers, and then cycling through them, because we don't do what it takes to retain people. That is true (and it won't change, so we need to behave like it won't...), but that is not the only reason. An inheritance hierarchy in a large program that makes sense today might not make sense in a year or two. Refact…

I write Apple UIKit apps. I am looking forward to using SwiftUI, which is designed to afford use of Protocol-Oriented Programming, reactive/observer stuff, and a lot of lower-state stuff. I think it would have made the work I've been doing in the last few days, much easier.

But if you use UIKit, then it's fairly important to use classic MVC (not MVVM), as that is what the SDK was specifically designed for. Trying to coerce it into other models just causes a lot of extra pain and complexity.

Also, there are models that have been specifically designed (I won't talk about which), to introduce extra complexity. These are made to allow a design to be "broken up," so that parts can be assigned to different developers.

> and it won't change, so we need to behave like it won't...

I sincerely hope that you're wrong. It's been an unmitigated disaster.

Re: Hang your code out to DRY

#58

Earlier quoted context omitted.

Exactly. I find it helps to also state that it doesn't mean "Don't Repeat Characters"

I've pointed out in the past that if the characters you're deduplicating don't actually have the same meaning, you're just compressing your code; I've been trying to popularize labelling that kind of aggressive misapplication of DRY "Huffman coding".

On the other hand, if you keep repeating the same character sequence there is probably some structure on your code that you can also abstract away. You are not restricted to factoring business concepts.

Re: Hang your code out to DRY

#59

I find it fascinating that people are so against inheritance/polymorphism, these days. That's one of the absolute best ways to DRY. factoring out common base classes is a classic OO exercise. It's possible to drastically reduce the size of a codebase, and the potential error exposure, by doing some simple extractions.

To me, inheritance and polymorphism are two different things. Polymorphism is about different units implementing an interface or equivalent protocol and that rocks. Inheritance is, essentially, dumping a bunch of code into your new class, and most of the time just imposes constraints and breaks API boundaries for no good reason. After studying and doing OOP for about 5 years, I don't see the advantages of inheritance…

> After studying and doing OOP for about 5 years, I don't see the advantages of inheritance over composition.

I mean, "prefer composition over inheritance" was in the GoF book which is from 1994, and is one of the core OOP books. If you've just been studying OOP for five years, it's likely that you weren't even BORN when this was already industry-level good practice.

Re: Hang your code out to DRY

#60

Earlier quoted context omitted.

I think the old "remove duplication the third time you write it" is bad advice as well, to be honest. First off, it excuses some really egregious behaviour like copying entire large chunks of code representing an identical concept just because "I haven't copied it twice yet". I've seen an entire controller and all related views copied wholesale because it needed to be placed in another area of the app (with identical…

> I think the old "remove duplication the third time you write it" is bad advice as well, to be honest. Same. “That’s just DRY with extra steps!”

No post body was provided.
Post reply on HN