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

161–170 of 501 posts

Re: DRY is an over-rated programming principle?

#161

Post by _0ffh »

yoz-y wrote: post #126
tcfhgj wrote: post #122

Earlier quoted context omitted.

> I think the article fails to show particularly problematic examples of DRY. E.g. merging two ~similar functions and adding a conditional for the non-shared codepaths. shudders Not a problem of DRY, but bad code structure. Just keep the two functions and pull the shared code-path out

Not all the time. When the similar code mixes types and the common codepaths are sprinkled multiple times over it you can either have the code there twice, or have an overcomplicated templated common function. In these cases factorizing may or may not be a good idea.

I think it's just that for every complex topic, any general rule will break down at some point. That doesn't tell you that the rule is bad, but to learn how to tell when you're dealing with such an exception.

Re: DRY is an over-rated programming principle?

#163

Post by [deleted] »

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…

[deleted]

Re: DRY is an over-rated programming principle?

#165

Post by hinkley »

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…

> Assumption of incompetence to support your argument.

Okay, but it kind of is about incompetence. And by “it” I mean everything. Look, we all remember that first time we all realized that adults are just winging it most of the time. Almost nobody knows what they are doing. Half the people who “know” actually know the least.

> DRY does NOT lead to over-complicating things.

Don’t Repeat Yourself is a terrible acronym because what it stands for is exactly the opposite of what people do. Not doing something is avoidance, opting out, like “don’t push your sister” vs “be nice to your sister”.

What most people do is they realize they have already repeated themselves, or someone else, and they rip it out. They deduplicate their code. Avoidance definitely can “lead” somewhere, but deduplication is active, and that can often be headed the wrong way, either directly or obliquely.

The Rule of Three is much clearer on this. You get one. There’s nothing to do when you see you’ve duplicated code - except to check if you’re the first or not.

Re: DRY is an over-rated programming principle?

#166

Post by usrusr »

NikhilVerma wrote: post #70

I had a general guidelines in my previous company which I follow to this day to great results. If a piece of code is duplicated thrice, it's ok. If a piece code is duplicated four times, then you must extract it.

Solve every problem once.

Two times repeated can be much worse than ten times repeated if one is a dizzying mess (e.g. to handhold some tragic third party API) and the other is a trivial sequence of instructions you'd understand even if dementia forced to read with a finger on the current line. That code wouldn't qualify as a problem so it isn't affected by the rule

(but you might still de-duplify if you know that if it changes it should change uniformly)

Re: DRY is an over-rated programming principle?

#167

Post by sebastianconcpt »

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 wannabe your friend hahaha

No really, you're absolutely on point. The post is not worth the time, the case against DRY is too weak.

Sounds like a kid complaining about pushing DRY in a direction that overcomplicated things for him because of himself and instead of improving himself he choosed to attack "an uncomfortable principle".

Re: DRY is an over-rated programming principle?

#168

Post by dspillett »

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.

Though note that DRY can itself be premature optimisation of the codebase.

Re: DRY is an over-rated programming principle?

#169

Post by ehnto »

wruza wrote: post #93
ehnto wrote: post #29

Earlier quoted context omitted.

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 refactori…

I have taken what you might consider low-DRY approach also so it's interesting to see what mechanisms people use to manage reuse without introducing complexity into the system itself.

I think taking another look at project agnostic generators is something worth doing too. It has the benefits of automating some of the duplication without the rigidity of deep abstractions and dependencies. I am still exploring that though.

Re: DRY is an over-rated programming principle?

#170

Post by noisy_boy »

beaker52 wrote: post #42

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…

> 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.

What is the big benefit you gained from doing that compared to calling, say, a service method call in the controller?

    costService.generateCost(newPrice);
Is it really that difficult to go to the service method definition? With inlining at the controller level, in order to unit test generateCost, you'll now have to deal with authentication/authorization/request handling related infrastructure which has nothing to do with cost calculation.
Post reply on HN