Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hang your code out to DRY

johan.hal.se

Post reply on HN
Print view View original

21–30 of 82 posts

Re: Hang your code out to DRY

#21

Post by terrortrain »

ebiester wrote: post #6

My first heuristic is: If I change the code in block A, is it assured that I will need to change the code in block B? My second heuristic is: Can I name the method I wish to de-duplicate in a way that is honest for all cases I wish to cover, yet explains its business purpose? The more it deviates from these heuristics, the more likely I am to duplicate the code in object oriented programming.

I wish I saved the source, but I saw somewhere the term: "Don't repeat concepts"

While it doesn't spell out a word, I think it's much better advice than DRY, and better aligns with your heuristics.

Re: Hang your code out to DRY

#22

Post by Jtsummers »

terrortrain wrote: post #21
ebiester wrote: post #6

My first heuristic is: If I change the code in block A, is it assured that I will need to change the code in block B? My second heuristic is: Can I name the method I wish to de-duplicate in a way that is honest for all cases I wish to cover, yet explains its business purpose? The more it deviates from these heuristics, the more likely I am to duplicate the code in object oriented programming.

I wish I saved the source, but I saw somewhere the term: "Don't repeat concepts" While it doesn't spell out a word, I think it's much better advice than DRY, and better aligns with your heuristics.

That's actually more or less how DRY is described in The Pragmatic Programmer (20th anniversary edition):

> Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

Further on:

> Dry is about the duplication of knowledge, of intent. It's about expressing the same thing in two different places, possibly in two totally different ways. [emphasis in original]

And the next paragraph:

> Here's the acid test: when some single facet of the code has to change, do you find yourself making that change in multiple places, and in multiple different formats? Do you have to change code and documentation, or a database schema and a structure that holds it, or...? If so, your code isn't DRY.

Re: Hang your code out to DRY

#23

Post by marcus_holmes »

ChrisMarshallNY wrote: post #8

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.

Because a lot of us learned the hard way that inheritance can very easily lead to a dark place. Changing behaviour on a grandparent object in specific circumstances related to the implementation of a child object gets really nasty.

Re: Hang your code out to DRY

#25

Post by gfunk911 »

terrortrain wrote: post #21
ebiester wrote: post #6

My first heuristic is: If I change the code in block A, is it assured that I will need to change the code in block B? My second heuristic is: Can I name the method I wish to de-duplicate in a way that is honest for all cases I wish to cover, yet explains its business purpose? The more it deviates from these heuristics, the more likely I am to duplicate the code in object oriented programming.

I wish I saved the source, but I saw somewhere the term: "Don't repeat concepts" While it doesn't spell out a word, I think it's much better advice than DRY, and better aligns with your heuristics.

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

Re: Hang your code out to DRY

#26

Post by cjfd »

If there is one single article about programming that I positively hate it is 'duplication is better than the wrong abstraction'. As the Jason Swett article points out the article seems to install a sort of fear of refactoring. If there is a 'wrong abstraction' nobody will every change it and now we are doomed to live with this wrong abstraction for all of eternity. The wrong abstraction can be turned into the right abstraction or can be undone if it is really not going anywhere. If that is what is happening at least people are trying to improve the code and if people try something it will eventually work. In many cases a bad code base is difficult to change because it is wrong in so many respects that it is difficult to tell where to start. If there is an attitude of refactoring and improvement things that are bad can be taken out quickly. Now, one should, of course not be stupid about removing duplication. If two functions just look vaguely similar but this is more of a coincidence than something that occurs because of the nature of the problem that these two functions are solving then they should absolutely not be one abstraction.... I suppose one might need to point that out to some developers but certainly not to ones who have been developers for some time and who actually have some talent as developers.

Re: Hang your code out to DRY

#27

Post by sfvisser »

Abstraction is inherently not about deduplication, it is about capturing intent and meaning. About the universality of certain concepts within your code base. Either based on your problem domain or in the context of your application architecture.

Once you abstract only to shorten your code you’ll likely regret it quickly.

Re: Hang your code out to DRY

#29

Post by horsawlarway »

cjfd wrote: post #26

If there is one single article about programming that I positively hate it is 'duplication is better than the wrong abstraction'. As the Jason Swett article points out the article seems to install a sort of fear of refactoring. If there is a 'wrong abstraction' nobody will every change it and now we are doomed to live with this wrong abstraction for all of eternity. The wrong abstraction can be turned into the right…

Bad abstractions tie together components that shouldn't have been tied together.

Too many bad abstractions are how you quickly end up with that "Bad code base" that you believe is difficult to change - Things are wrong because they're tied together in ways that don't actually make sense, and changing code to support refactoring one use-case creates a wave of cascading changes to other places those abstractions are touched/consumed. If you miss one, or forget an edge case, or have a skimpy test suite - suddenly that refactoring you're so keen on is what's introducing new things that are "wrong" - because they shouldn't have been tied together but were, and you don't understand or remember all of the edge cases.

Basically - My rebuttal is this: It's very easy to refactor a codebase with duplication and introduce an abstraction for the current behavior. It's very HARD to refactor a codebase riddled with abstractions that shouldn't be there.

This means that by default - abstractions should only be introduced very carefully. Refactoring is fine, but you're paying more to refactor a bad abstraction than to refactor duplication. Good programmers understand that most of their value isn't in what their code looks like - it's in what it does for the users. Duplication can feel dirty, and it tends to trigger a "puzzle game" mentality in a lot of programmers, who want to fit the pieces together to make it pretty. AVOID THIS INSTINCT.

Re: Hang your code out to DRY

#30

Post by chrisweekly »

terrortrain wrote: post #21
ebiester wrote: post #6

My first heuristic is: If I change the code in block A, is it assured that I will need to change the code in block B? My second heuristic is: Can I name the method I wish to de-duplicate in a way that is honest for all cases I wish to cover, yet explains its business purpose? The more it deviates from these heuristics, the more likely I am to duplicate the code in object oriented programming.

I wish I saved the source, but I saw somewhere the term: "Don't repeat concepts" While it doesn't spell out a word, I think it's much better advice than DRY, and better aligns with your heuristics.

Related tangent: "AHA" (Avoid Hasty Abstractions) is a decent counter to the over-application of DRY. IME, people reach for DRY too quickly, at the expense of other worthy but more subtle principles.
Post reply on HN