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

DRY is an over-rated programming principle?

gordonc.bearblog.dev

Post reply on HN
Print view View original

81–90 of 501 posts

Re: DRY is an over-rated programming principle?

#81

Post by bigDinosaur »

fartsucker69 wrote: post #18
mavu wrote: post #13

> Instead of our code being architected around the concept of how pizzas are made in the abstract, its architecture is tightly coupled to the specific needs of these two pizzas that we happened to be dealing with. The chance that we will be putting this code back the way it was is extremely high. Mistake 1: Switch from DRY to premature optimization. > You might think that legit reasonable developers but would not act…

I don't read coding opinion articles like OP but I like to check out comments. > DRY does NOT lead to over-complicating things. That is not true. I dive around foreign code bases a lot and dry-ness is actually a significant complicating factor in understanding code, because you're jumping around a lot (as in physically to different files or just a few screens away in the same file). As in, inherently every time it's…

DRY makes it harder to actually understand the system as a whole in some sense, since it usually means some indirection has been added to the program. However, it avoids the one thing that actually makes me pull hair out: code that looks the same because it was duplicated but is just different enough to trip you up because each area it was used required minor syntax changes that had major implications for the result.

Re: DRY is an over-rated programming principle?

#83

Post by contravariant »

The code in the second example is horrible and for some reason used incorrectly by the author.

My usual approach would be something like:

    def make_pizza(left_toppings, right_toppings=None):
        if right_toppings is None:
             right_toppings = left_toppings
    
        ...
through really it should probably be

    def make_pizza(toppings=None, **kwargs):
        if toppings is not None:
            kwargs['toppings_left']  = toppings
            kwargs['toppings_right'] = toppings

        return requests.post(PIZZA_URL, kwargs)
If this logic should even be handled in the application itself at all (not sure why you'd choose to make a breaking change to the API rather than extending the API, though changing the make_pizza function to keep the code working after an API change is the correct response).

I'm also not sure why the author chose to make the function capable of handling an arbitrary number of arguments, or why after doing so he chose to incorrectly invoke it on a list.

Re: DRY is an over-rated programming principle?

#84

Post by tmnvix »

I think DRY is one of the first pieces of advice that many programmers come across. Taking it to heart as a beginner it has the advantage of encouraging you to sometimes stop and give a bit more thought to what you are actually doing. Is this essentially the same as what I'm doing over there? How is it different? Why is it different? Etc...

As you gather experience you can recognise these patterns more easily and develop a stronger intuition for when you should pursue a DRY approach or just leave things as they are. You might even choose to make two things even more similar so that they feel more familiar (i.e. choosing to be even less DRY!)

Re: DRY is an over-rated programming principle?

#85

Post by nine_k »

bigDinosaur wrote: post #81
fartsucker69 wrote: post #18

Earlier quoted context omitted.

I don't read coding opinion articles like OP but I like to check out comments. > DRY does NOT lead to over-complicating things. That is not true. I dive around foreign code bases a lot and dry-ness is actually a significant complicating factor in understanding code, because you're jumping around a lot (as in physically to different files or just a few screens away in the same file). As in, inherently every time it's…

DRY makes it harder to actually understand the system as a whole in some sense, since it usually means some indirection has been added to the program. However, it avoids the one thing that actually makes me pull hair out: code that looks the same because it was duplicated but is just different enough to trip you up because each area it was used required minor syntax changes that had major implications for the result.

Repetition also makes it harder to understand a system: not only do you have to read more, you also need to remember and compare repeating fragments that may be identical or just similar.

What makes it easier to understand a system is simplicity. I'd argue that DRY, deployed with a right strategic plan, usually does more to simplify things than does copy-paste.

But, as any tool, DRY is but a tool; to be useful it requires some skill.

Re: DRY is an over-rated programming principle?

#88

Post by laserlight »

MichaelGlass wrote: post #31
fartsucker69 wrote: post #18

Earlier quoted context omitted.

I don't read coding opinion articles like OP but I like to check out comments. > DRY does NOT lead to over-complicating things. That is not true. I dive around foreign code bases a lot and dry-ness is actually a significant complicating factor in understanding code, because you're jumping around a lot (as in physically to different files or just a few screens away in the same file). As in, inherently every time it's…

Agreed. To use the example from the article `make_pizza(["pepperoni"])` What does `make_pizza()` do? It could be a lot or it could be a little. It could have side-effects or not. Now I have to read another function to understand it, rather than easily skimming the ~four lines of code that I would have to repeat. I think the article fails to show particularly problematic examples of DRY. E.g. merging two ~similar func…

> What does `make_pizza()` do? It could be a lot or it could be a little. It could have side-effects or not. Now I have to read another function to understand it, rather than easily skimming the ~four lines of code that I would have to repeat.

This is not a problem of DRY. This is a problem of wrong abstraction and naming. If the function is just four lines, it could easily be named `make_and_cook_pizza`. In the alternative scenario where those four lines are copy pasted all over the place, one is never sure if they are exactly the same or have little tweaks in one instance or the other. Therefore, one has to be careful of the details, which is much harder than navigating to function definition, because in this case you cannot navigate to other instances of the code.

Re: DRY is an over-rated programming principle?

#89

Post by undoware »

Misses the most important reason.

Repetition creates symmetrical cases. As they say in German, 'einmal ist keinmal' -- once is never. Overly DRY code is incredibly non-educational.

Why?

Because you learn by comparing and contrasting -- if you can't compare, you can't contrast, and therefore, you cannot learn.

Re: DRY is an over-rated programming principle?

#90

Post by Double_a_92 »

dvh wrote: post #59

I have reached similar conclusion. DRY projects tend to snowball over the years into mess where every minor change is insanely difficult, breaks everything and code is hard to read, bugs are difficult to solve, diffs are difficult. WET code (opposite of DRY code, often starts as copy pasted) has more code, more typing, but the diffs are simple, bugs are simple (often you simply forgot to copy piece of code into 7 dif…

Until you end up with multiple similar pieces of code, that seem to do exactly the same thing except for a few small changes... and you wonder if maybe all the other copies would benefit from those changes too.
Post reply on HN