Live data from Hacker News

DRY is an over-rated programming principle?

gordonc.bearblog.dev

141–150 of 501 posts

Re: DRY is an over-rated programming principle?

#141
post #74
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…

If you have the same code copied to several places it makes it much harder to maintain. If there you find a bug in that code block then you have to fix it in several other places, and if you forget some, a bug that you thought you had already fixed might arise again.

How often do you really write the same piece of business logic code in multiple places?

I think discussion is that mostly it really is different code that only superficially looks the same.

I don't like pizza example.

But I have seen more issues because people were trying to cram code that looks the same in one function than some bug needed to be fixed multiple times because code was duplicated.

You also have layers of code and DRY best applies to things like "SaveStuffToDatabase" or framework code. Where a lot of business code can still be better off duplicated because usage will evolve in different ways like: CreateNew vs EditExisting - there is a lot of business cases where when creating new entity you want to set some values that should never be available in Editing - but saving to database should be just saving to database...

Re: DRY is an over-rated programming principle?

#142
> "All these ideas are great. But remember that the fundamental goal here, is to send a POST request with a single JSON object."

This. A million times this.

IMO, the single most important principle is still "Keep It simple when you can, make it complex when you have to."

A system that is simple can be grokked quickly, meaning it can be debugged quickly, modified quickly, new developers can be onboarded quickly,...

Yes complex systems have to exist. Some tasks are complex, and require complex solutions. BUT: Complexity should come into play when it is necessary.

It is perfectly okay to design simple solutions for simple tasks. Yes, sometimes this means ignoring things like DRY.

Re: DRY is an over-rated programming principle?

#143
post #103

Earlier quoted context omitted.

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…

But that is usually a problem with abstraction, rather than a problem with a method call. If I can trust what make_pizza does, that is much faster to read than any four lines of code. A functional style certainly helps. I get the pizza in my hand and don’t have to worry that anyone left the oven on.

> If I can trust what make_pizza does

You can't, unless it's in a standard library or a core dependency used by millions of people.

That's one of the reasons why functional code is generally easier to read. A lambda defined a few lines above whatever you're reading gives you the implementation details right there while still abstracting away duplicate code. It's the best of both worlds. People who's idea of "functional programming" is to import 30 external functions into a file and compose them into an abstract algorithm somewhere other than where they're defined write code that's just as shitty and unreadable as most Java code.

Re: DRY is an over-rated programming principle?

#145

As anything it is just a tool in our toolbelt and should be used carefully. If our system contains same user validation in 2 places, changing it in 1 place may lead to issues, which are difficult to discover. However forcefully implementing DRY everywhere can lead to coupling and lack of separation between modules and influence deployments, and work of different teams. Its more difficult to build context of the imple…

[deleted]

Re: DRY is an over-rated programming principle?

#146
post #97

Surely you'd remove repetition by doing this instead: hawaiian_pizza = { crust: "thin", sauce: "tomato", cheese: "regular", toppings: ["ham", "pineapple"] } pepperoni_pizza = { crust: "thin", sauce: "tomato", cheese: "regular", toppings: ["pepperoni"] } def make_pizza(pizza): requests.post(PIZZA_URL, pizza) This isn't better just because it's DRY, it also keeps the data separate from code, which makes it usable elsew…

Even better IMO (although devolving into pseudo code):

    pizza_base = {
        crust: "thin",
        sauce: "tomato",
        cheese: "regular",
        toppings: []
    }

    hawaiian_pizza = pizza_base {
        toppings: ["ham", "pineapple"]
    }

    pepperoni_pizza = pizza_base {
        toppings: ["pepperoni"]
    }

    def make_pizza(pizza):
        requests.post(PIZZA_URL, pizza)

Re: DRY is an over-rated programming principle?

#147
To help figure out when to DRY or leave wet i like to use the rule of 3. Where a piece of code needs to be repeated 3 times before it is DRYd up. You can adjust this number from 3 to whatever you would like.

What I really like about rule of 3, vs rule of 2, is that it allows more time to go by that may lead to the two pieces of code no longer being identical as requirements change. Which would either remove the need for the abstraction or allow for a more accurate abstraction.

Re: DRY is an over-rated programming principle?

#148
post #76

Earlier quoted context omitted.

The reasoning behind discouraging premature optimization makes no distinction between "micro optimizations" and any other kind, the purpose of this guidance is to minimize wasting time building unnecessarily complex solutions based on untested performance assumptions.

It does not generalize from low level micro optimizations to high level sensible system design. At the low levels you really have no idea where the performance bottle necks are without profiling and getting actual numbers to work with. At the high level you pretty much have a clear idea of what roughly the system is supposed to do and what performance characteristics you want.

I think this comes down to a level of experience.

If you're writing and enterprise app and lean back in your chair and start to think about speeding things up with loop unrolling and avx instruction sets then you're doing the premature optimization thing.

But trying to limit large nested loops is easy fruit that doesn't take much effort to pick.

Re: DRY is an over-rated programming principle?

#149
Have you ever seen the complete opposite? non-DRY all over the place? No variables or constants defined, same values manually inserted all over the code? Or same code with slight differences duplicated all over the place. - When you see that, you'll realize how useful the DRY principle is.

Re: DRY is an over-rated programming principle?

#150
DRY has the same idea as modules. Write once and re-use it.

This article is the result of someone exploring a new idea and cussing it out because he has to change his ways. I've been there countless times.

DRY is not overrated. DRY is a time saver in the long run. Why is this even on top of the 1st page, how new are you to development anyway?

Sorry but I'm really getting pissed off by people wasting my time with useless articles lately. It's getting out of hand.

Post reply on HN