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

321–330 of 501 posts

Re: DRY is an over-rated programming principle?

#321

Post by gcassie »

ihateolives wrote: post #17

Personal anecdata. I have been increasingly aware of my own mental patterns during development and I've noticed that often I've been sitting and mulling over refactoring to some sort of universal solution instead of getting on with the work and getting things done. There are instances when I could've finished the task twice as fast if I would've just went ahead and done it with repeating code instead of thinking of c…

I can relate to this. I think Casey Muratori coined the maxim "write usable code first". I often mutter that to myself when I'm trying to design some crazy system rather than just solving the problem at hand.

Re: DRY is an over-rated programming principle?

#322

Post by dragonwriter »

Clubber wrote: post #314

DRY is about code, not data. If you see two methods do the same thing somewhere in their code blocks, separate the duplicate logic into a separate method, then call that method when you need to execute that logic. The reason for this is maintainability. Say that logic needs to be changed. If you didn't break it out into a callable method, you'd have to find all the places you use that logic and change it. If it is a…

> DRY is about code, not data.

No, it's about representation of information in a system, as your own Wikipedia link states right up at the top of the second paragraph. Code and data are both forms in which information may be represented ina a system.

Re: DRY is an over-rated programming principle?

#323

Post by ArrayBoundCheck »

pech0rin wrote: post #23

Not sure why this is on the frontpage. Not only are there a bunch of typos, a bunch of code doesn't actually work the way they said it does. Also gotta love hating on the 10x developer or whatever for saying you are wrong. EVERYTHING HAS TRADEOFFS. Every single thing has tradeoffs. Obviously you should not write terrible, brittle code. The reason DRY is important is because when you start duplicating code, having 30…

> EVERYTHING HAS TRADEOFFS

Bullshit. What's the tradeoff on using `gets` vs any other function?

Nothing. Absolutely nothing. `gets` is wrong 100% of the time period.

If you're wrong its not a trade and a lot of things in this article and about dry is wrong

Re: DRY is an over-rated programming principle?

#324

Post by kosmotaur »

codesnik wrote: post #206
captainmuon wrote: post #190

Every time I read an article like this, "why is overrated", I think, yeah you are right in theory. But most places I have worked, these best practices were not overused, but underused. If you have the problem that your coworkers create unneccessary abstractions, I envy you, because I have so often had the opposite problem. Maybe this is not the case if you work in a great software development team. But if you work so…

I sometimes use term "mid-level engineer syndrome", for "too many levels of abstraction in the codebase". It is very common in my experience. And untangling it's usually harder then extracting common stuff from "dumb" code. I usually don't DRY things up until three repetitions. And in test code - try to not DRY at all, copypaste is a friend of readable and mantainable specs.

> copypaste is a friend of readable and mantainable specs

Another generic statement: copypaste (as I understand you mean the opposite of extracting common code) between specs goes against single responsibility. Rather than `setupUser()` you open a connection, create a user fixture, write it to the db, and then paste that across all the specs. Doing quite a lot.

I can imagine a spec with let's say 20 cases. Arrangement of each takes about 6 lines to load something, change some state the test subject depends on, the usual stuff, like in the above example.

A week from now, 10 cases need an extra line of setup, which you dutifully paste across the specs which require them. You put it somewhere in the middle, as it needs an id from the first step of 6.

This happens once or twice. The commonality of the original 6 copy pasted all over the place is hashed up, interspersed with calls specific to each test. The linking factor between those 6 lines is now obscured and requiring careful analysis if only those 6 need to change.

This can be avoided if you extract the common bits out early on. Rule of three is your friend if you don't want to rush it.

Re: DRY is an over-rated programming principle?

#325

Post by slowmovintarget »

dragonwriter wrote: post #317
gcassie wrote: post #301

Earlier quoted context omitted.

Partially agree. I think SPOT (I'd always heard it called single source of truth) is a more universally applicable paradigm than DRY. Having said that, the cost of creating dependency chains is often underestimated. Overly dogmatic adherence to SPOT/SST can lead you to make the wrong tradeoff on coupling two unrelated areas of your codebase to unify some trivial truth. I'd also say there is a lot of nuance about what…

> I think SPOT (I'd always heard it called single source of truth) is a more universally applicable paradigm than DRY. “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system” is the verbatim definition of DRY from when the DRY principle was first articulated.

And "knowledge" is a far more applicable word than "truth."

Truth implies facts, knowledge implies understanding the meaning and associated course of actions.

This is the second time in as many days that I've read something purporting to go beyond some original. The one yesterday was "we need more than the four types of documentation." All the examples fit into the four types as originally defined.

In HR training, there was even an entire segment on the "Platinum rule" because the Golden rule isn't good enough. Yet anyone who works to understand the Golden rule to any depth knows that it encompasses every "enhancement" the Platinum rule intends without any of the side effects.

What kind of failure is occurring such that definitions don't function any more, I wonder?

Re: DRY is an over-rated programming principle?

#326

Post by mellavora »

monsieurbanana wrote: post #186
mellavora wrote: post #178

Earlier quoted context omitted.

> You should absolutely ALWAYS write non-pessimized code by default. Some days I come here just for the typos. :) Today I've seen two good ones, number zero was "Costco had to stop returns on TVs because people were “renting” them for free for the superb owl."

Where is the typo? And the usefulness of your comment?

the typo is "non-pessimized code", which should be "non-optimized code".

I see humor in thinking if my code is pessimistic enough. Have I assumed that the edge cases will happen and worked around them? Do I expect (and handle) crashes, i/o failures, network timeouts, etc?

"code pessimism" could be an interesting metric.

The typo in the other post was "superb owl" which should have been "super bowl". Several people on that thread enjoyed the typo, including a comment from CostalCoder saying "Please, please do not correct that typo!"

https://news.ycombinator.com/item?id=31999048

Re: DRY is an over-rated programming principle?

#328

Post by gary_0 »

epage wrote: post #220
layer8 wrote: post #188

A better formulation of DRY is SPOT (Single Point Of Truth). Definitions (code, data) that represent the same “truth”, i.e. when one changes all have to change to represent a consistent truth, should be reduced to a single definition. For example, if there is a rule that pizzas need at least one topping, there should only be a single place where that condition is expressed, so that when the rule changes, it isn’t jus…

I agree with this as it puts emphasis on semantics rather than syntax and encourages focusing on intentionally similar code rather than unintentional. A related principle is what I call code locality. Instruction locality is the grouping of related instructons so they can be the CPU's cache (can an inner loop fit all in cache). Similar for data locality. Code locality is for humans to discover and remember related co…

On a similar note, tree/graph structures should be avoided versus lists unless there is a good reason. Flat is better than nested. A linear block of code is far easier to reason about than a network of function calls, or (heaven forbid) a class hierarchy.

Not that such tools don't have their place, but I've seen too much convoluted code that has broken simple things into little interconnected bits for no reason other than someone thinking "this is how you're supposed to write code" and having fun adding abstractions they Ain't Gonna Need.

Re: DRY is an over-rated programming principle?

#329

Post by BurningFrog »

epage wrote: post #220
layer8 wrote: post #188

A better formulation of DRY is SPOT (Single Point Of Truth). Definitions (code, data) that represent the same “truth”, i.e. when one changes all have to change to represent a consistent truth, should be reduced to a single definition. For example, if there is a rule that pizzas need at least one topping, there should only be a single place where that condition is expressed, so that when the rule changes, it isn’t jus…

I agree with this as it puts emphasis on semantics rather than syntax and encourages focusing on intentionally similar code rather than unintentional. A related principle is what I call code locality. Instruction locality is the grouping of related instructons so they can be the CPU's cache (can an inner loop fit all in cache). Similar for data locality. Code locality is for humans to discover and remember related co…

This is a pretty good description of the motivation for OOP.

Re: DRY is an over-rated programming principle?

#330

Post by _gabe_ »

mellavora wrote: post #326
monsieurbanana wrote: post #186

Earlier quoted context omitted.

Where is the typo? And the usefulness of your comment?

the typo is "non-pessimized code", which should be "non-optimized code". I see humor in thinking if my code is pessimistic enough. Have I assumed that the edge cases will happen and worked around them? Do I expect (and handle) crashes, i/o failures, network timeouts, etc? "code pessimism" could be an interesting metric. The typo in the other post was "superb owl" which should have been "super bowl". Several people on…

I think they used that term on purpose. Non-pessimized in this case is the same as optimized, and I believe it's a reference to this video https://youtu.be/7YpFGkG-u1w
Post reply on HN