DRY is an over-rated programming principle? • Hacker News Board

Re: DRY is an over-rated programming principle?

#91

Post by makeitdouble » Thu, Jul 07, 2022, 9:01 AM UTC

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…

> This sounds dumb but it just simply is much harder to keep context about what's going on around if you can't refer back to it because it's on the same screen or one short mouse scroll above or below your current screen.

To note, a common effect of not DRYing functions is an increase in local code length.

In many code bases that lived long enough, that means screens and screens of functions inside the module/class files. It is still easier to navigate than between many files, but not by that much in practice (back/forth keyboard shortcuts go a long way to alleviate this type of pain)

Re: DRY is an over-rated programming principle?

#92

Post by dragonwriter » Thu, Jul 07, 2022, 9:03 AM UTC

> I suspect any developer reading this is aware of the DRY principle because it is just so ubiquitous. If not though, you just need to know that it stands for "Don't Repeat Yourself" and is generally invoked when advising people to not copy and paste snippets of code all over the place and instead consolidate logic into a central place.

Well, no.

What you actually need to know is the next layer out: DRY stands for Don't Repeat Yourself, sure, but Don’t Repeat Yourself isn't the rule, it's a short phrase that is supposed to be a memory cue for the principle “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”.

If all you know is “Don’t Repeat Yourself”, you don't know the principle, and you can neither apply nor critique it.

#1 is simply applying the memory cue as if it were the principle. Yeah, don't do that.

#2 is, well, no, you only refactor to extract a bit of knowledge to a common place where it is immediately reused: there is no presumption of reusability, it is demonstrated.

The specific example they use of how this might be done wrong is...so bad.

Starting with: the example code that they suggest is bad design but works does not work.

  make_pizza([left_topping, right_topping])

gives args a length of 1, not 2, but their function definition relies on it having length 2, and using that to distinguish from the simple case.

Re: DRY is an over-rated programming principle?

#93

Post by wruza » Thu, Jul 07, 2022, 9:06 AM UTC

ehnto wrote: post #29

wruza wrote: post #9

What forced me most to use DRY in inappropriate ways is typing out blocks of the same code again and again. Then I realized that and began to maintain and use easily expandable snippets with fillable placeholders. It turned out that my mind had no objections against repetitive code at all, and the clarity of it has only increased, due to the lack of context switches and parametric entanglement.

Genuinely curious, what do you do for refactors? Create a new snippet and go replace all the required instances?

Yes, e.g. when I need to add a new line/block of code, I just search for a pattern and edit there. When refactoring demands heavy structural cross-module changes, I just don’t do it honestly. What’s dead is dead, but I may do a “guided” side by side rewrite.

I don’t touch snippets unless there is a good reason to do that. They are my general templates, not per-project tools.

In most of my code, the need for refactoring was mostly a consequence of building a too rigid high-tech structure which with time turned out to not fit the job anyway. Figured out I can avoid it by not building it, and antiDRY also plays a role in it (albeit mostly psychological).

Re: DRY is an over-rated programming principle?

#94

Post by nicbou » Thu, Jul 07, 2022, 9:06 AM UTC

norman784 wrote: post #47

charles_f wrote: post #26

I see DRY as a smell, not a principle. If you see clones (same code in multiple places), then it's likely indicating that there is something that can be factorized. Now the question you should ask yourself before factorization is whether the duplication is coincidental (as the author shows) or if it's because the logic was copy pasted. Most of the time it's the second case, and duplicate code does make maintenance ha…

In my case when I was junior I tried to be very smart and try to DRY a lot, but I found that most of the times is better to write "dumb" code and repeat yourself if the complexity is not worth, also as you stated if your function is used in a lot of places for slightly different things is just so easy to break something without noticing and also harder to test. So I agree with you, as developer you should know when d…

This works until someone updates code in one place, but not the other, and subtle bugs are introduced.

DRY / single source of truth offers a certain protection against such bugs.

Re: DRY is an over-rated programming principle?

#95

Post by Swiffy0 » Thu, Jul 07, 2022, 9:08 AM UTC

Wtf.

If your use-case is that the user can select the crust, sauce, cheese and toppings for a pizza, just pass that shit to the make_pizza function with the help of enums and arrays. If you want to have predefined pizzas, you'd simply make a dictionary of pizza templates with all the options that the make_pizza function needs and/or if you wanna be fancy, you'd make a separate make_pizza_from_template function, but definitely not a make_pepperoni_pizza function, because that's just encoding data as a code in a silly way that arguably not even a factory pattern.

No solution will be able to cater to requirements that don't exist at the time of developing this pizza-application. You build it according to the requirements that exist and that is enough. It's not your fault if nobody cared to mention that the user should be able to arbitrarily subdivide the pizza and select options sepatately for each subdivision - that's a feature update and it's OK if the original program hadn't though of that. Just like you wouldn't scaffold ecommerce capabilities into a webpage "just in case", if there had been zero mention of such a need.

Re: DRY is an over-rated programming principle?

#96

Post by goatlover » Thu, Jul 07, 2022, 9:08 AM UTC

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…

Why would you want to maintain basically the same code in multiple places? That sounds more error prone to me. If the DRY code becomes too complicated then refactor it as needed.

Re: DRY is an over-rated programming principle?

#97

Post by strken » Thu, Jul 07, 2022, 9:12 AM UTC

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 elsewhere. Defining fifty different types of pizza inline inside functions is a strange choice, because it tightly couples your pizza definitions to your pizza-making. What if you want to answer a question like "how many thin crust pizzas do we sell?"

Re: DRY is an over-rated programming principle?

#98

Post by wolframhempel » Thu, Jul 07, 2022, 9:13 AM UTC

I think the underlying meta principle here is: Don't be dogmatic in your following of principles. Make sensible choices for the use case at hand which might be informed by the spirit of principles, but don't treat them like some biblical commandment that has to be applied at all time.

Re: DRY is an over-rated programming principle?

#99

Post by samrocksc » Thu, Jul 07, 2022, 9:14 AM UTC

Do what's best for the situation, WET/DRY principles both have valid application use cases. They should be used to leverage the most advantageous effect for your usage.

Re: DRY is an over-rated programming principle?

#100

Post by gjulianm » Thu, Jul 07, 2022, 9:19 AM UTC

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…

I think that drawing conclusions from these examples is not productive at all. In the wild we're going to see functions such as

    def make_string_filename(s):
        # four lines of regex and replace magic

so that we have code like

    file_src = make_string_filename(object_name)
    file_dst = make_string_filename(object_name_2)

which is much more understandable than eight lines of regex magic where you don't even know what the regex is doing.

The problem of not knowing what it does or whether it has side effects or not is more a problem of naming and documentation than DRY. Even then, it's still better than repeating the code all over, simply because when you read and understand the function once, you don't need to go back. On the other hand, if the code is all over, you need to read it again to recognize it's the same piece of code.