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

41–50 of 501 posts

Re: DRY is an over-rated programming principle?

#41

Post by hsn915 »

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…

> Mistake 1: Switch from DRY to premature optimization.

"Premature optimization" is largely a bogus concept, because the meaning of "optimization" has shifted a lot since the concept was first created.

People now use optimization to mean "sensible design that does not needlessly waste resources".

In this meaning of optimization, "premature optimization" is a bogus concept.

You should absolutely ALWAYS write non-pessimized code by default.

What the original concept referred to is what people now call "micro optimizations". Sure, premature micro optimizations is often a waste of time. But this is irrelevant to the context of this discussion.

Re: DRY is an over-rated programming principle?

#42

Post by beaker52 »

I once worked on a project that was basically a simple My Account application/area for a train ticket retailer.

The backend itself held no data, but whoever built the backend had gone full service layer, with models and adapters to the upstream services that hold the data.

The result was a backend that was a pain in the ass to change, necessitating whole trees of file changes to build features.

So we started inlining everything. We just took it back to the request handlers. We started fetching, mutating and returning the data in the request handlers. Suddenly a change became modifying one function. Every endpoint was unique and didn't depend on anything else. Things became easy.

Halfway through the migration, someone got our effort reviewed by a principal engineer who told me "it wasn't SOLID", and my contract wasn't renewed. It didn't dishearten me.

Software design is meant to make change easier and proudly adding abstractions can be a bad thing.

Re: DRY is an over-rated programming principle?

#43

Post by frognumber »

In this case, the problem is with a bug creeping in:

            crust: "thyn",
DRY is about avoiding this class of cut-and-paste bugs too. Or with changing a string to a token, as it should have been:

            crust: THIN
The code isn't even correct. It's mixing JavaScript and Python. I'm also not sure why you'd declare functions for each type of pizza; that's data. I'm not sure about the context, but the right way is:

    def make_pizza(crust=THIN, toppings=[], cheese=REGULAR, sauce=TOMATO)
and then in each call, to override.

    make_pepperoni_pizza()
is bad code compared to

    make_pizza(toppings=[PEPPERONI])
All of the code in this post is horrible, and has easy solutions.

I feel dumber for having read this post, and even dumber for having responded.

Re: DRY is an over-rated programming principle?

#44

Post by thom »

DRY and Once And Only Once isn’t about slavishly identifying similar code blocks. It’s about trying to arrange your code so that a single idea is expressed in a single place.

The initial API here is actually quite nice - there’s a good separation of abstraction and specification, and I can see all the information about an individual pizza in one place. The idea of making a pizza and the recipe for each pizza exist once in their respective places.

It’s true that a common pitfall is to prematurely create abstractions before having concrete examples of how they’d be used. But DRY is a _refactoring_. It’s something you do to an existing codebase to better clarify its design, not necessarily something to strive for ahead of time. Much better to extract abstractions from existing examples.

I always remember the tale Ron Jeffries tells of Kent Beck actually _introducing_ duplication to allow both pieces of code to be refactored. Duplication can be an opportunity to refactor towards a clearer design, but it’s not a mechanistic thing to do without thinking.

Re: DRY is an over-rated programming principle?

#45

Post by ivxvm »

The first code example doesn't make sense. There is no good reason to write code like that which hardcodes payloads for different types of pizza. It's a realm of data. Realistically, those payloads will either be constructed by user in the UI, or they will be provided in json file as predefined variants.

Re: DRY is an over-rated programming principle?

#46

Post by xiphias2 »

,,To solve my sauce issue, maybe I could use an OOP style and have a PizzaOrderer class that can be subclassed for each pizza type, allowing each type to override sensible sauce/crust defaults.''

No, DRY doesn't mean that you should create classes just to prove your (invalid) point.

Re: DRY is an over-rated programming principle?

#47

Post by norman784 »

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 do duplicate code and when DRY, but overall try to maintain your code as simple as possible, that makes also easier to maintain.

Re: DRY is an over-rated programming principle?

#48

Post by fear91 »

ukoki wrote: post #32
fear91 wrote: post #14

DRY is better for performance (cache efficiency). It’s also less work for the compiler. Those might not be concerns of someone writing pizza CRUD in python.

DRY is not necesarily better for performance. Loop unrolling is extremely un-dry and often provides better performance. DRY can also lead to more branches which can lead to branch predictor misses which can impact performance. For example: the author's update to make_pizza to handle split pizzas introduces a branch where previously the code would have been branchless.

The “branch” looks like an easy cmove target. Moreover, while it might not have a branch in the func itself, you will have to have one somewhere higher in the control flow anyway.

As for loop unrolling, I bet you a loop with unrolled calls to 2 different unDRY functions will be slower (and not only because of the most certainly present extra branches to select for them)

Re: DRY is an over-rated programming principle?

#50

Post by qubyte »

Probably the most common comment from me in code reviews is about code being prematurely DRY’d out. Fortunately, I’ve found that mentioning the Rule of Three is usually enough to correct it, and it tends to stick in the mind. Waiting that little bit longer, more often than not there’ll be no third instance of some pattern and no need to abstract it. When a pattern does emerge, it’s a clearer one. Either way it’s less work.
Post reply on HN