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

331–340 of 501 posts

Re: DRY is an over-rated programming principle?

#331

Post by BurningFrog »

tpoacher wrote: post #221
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…

Occasionally, it's not clear if a single point of truth is entirely appropriate, or even if it is it can lead to tiresome extra levels of abstraction. In this case, I sometimes prefer a slightly different approach; let's call it CRAP - Cross Reference Against Protocol: instead of definitions effectively referring physically to the same point of truth, they are designed instead such that they simply cross reference ag…

Not sure if it fits within the CRAP idea, but sometimes I just write a test asserting that all duplicative definitions of X are equal.

Re: DRY is an over-rated programming principle?

#332

Post by Clubber »

dragonwriter wrote: post #322
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.

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

That's a little too broad to be useful, IMO. I learned the DRY principle before that book came out, and it was strictly about not repeating yourself in code. You can apply it to other things, but it was originally code. Normal form is a good example of applying DRY to RDBMS systems/schemas. "Single source of truth," is a good example of applying DRY to separate database systems. None of those were considered part of the DRY principle when I was starting out.

>They apply it quite broadly to include "database schemas, test plans, the build system, even documentation".

The article even hints those particular authors expanded on it beyond its original intent. They certainly didn't invent it.

Re: DRY is an over-rated programming principle?

#334

Post by BurningFrog »

lowercased wrote: post #207
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…

> People not able to factor out functions or structure their code in a readable way. Variables are called v1, v2, v3. Unit testing seen as a waste of time. CI seen as a fun toy. They lack the experience to even notice the difference. Had a colleague work under a 'team lead'. Needed to take a form with variable amount of rows of input data - max 50 - and take data, parse it, and store it. Took 20-30 lines of code. Nex…

At one of my earliest jobs, in a previous century, if statements were introduced to the language (RPG-3).

I was delighted, but the old-timers were quite suspicious of this experimental technology.

Re: DRY is an over-rated programming principle?

#335

Post by ARandumGuy »

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…

This article is acting like DRY means "never repeat yourself in any circumstance". And it's easy to come up with counter-examples if that's your starting point.

While there are certainly some DRY proponents that treat it like that, most discussions I've seen advocating for DRY treat it as a rule of thumb. There are always exceptions, but DRY will steer you in the right direction more often then not.

Re: DRY is an over-rated programming principle?

#336

Post by the__alchemist »

This article's conclusion and headline is shallow. The example is a good one about where (depending on context), adding abstraction to reduce repetition might add complexity. Great point! Repetition is fine in reasons like that.

It does not invalidate DRY concerns in general! For example, an important reason to avoid repetition is that it adds maintenance inertia. Where a setup that a single-location change is easy to experiment with and improve, one that's repeated several places becomes tougher to change. Ie, friction. I would argue this is also adding complexity - what the author seeks to avoid.

You could imagine contexts for the pizza example where the repetition doesn't make sense, and a refactor could make things easier. You can't tell alone from the snippet.

From the headline and concluding paragraph, it feels like a straw-man. eg overrated, and:

> "Well, obviously I'm not saying we should throw DRY completely out the window. I'm not sure it would actually be possible to write code that "never doesn't repeat itself". But I do think we should tone down knee jerk reactions to PRs that contain several repetitions of a block of code. There are at least a few cases where that might be the exact right thing to do."

Re: DRY is an over-rated programming principle?

#337

Post by BurningFrog »

dfee wrote: post #290
lowercased wrote: post #207

Earlier quoted context omitted.

> People not able to factor out functions or structure their code in a readable way. Variables are called v1, v2, v3. Unit testing seen as a waste of time. CI seen as a fun toy. They lack the experience to even notice the difference. Had a colleague work under a 'team lead'. Needed to take a form with variable amount of rows of input data - max 50 - and take data, parse it, and store it. Took 20-30 lines of code. Nex…

I regularly see code of the form `if(x == false)` as the author has a distrust of `if(!x)`. I guess the author just distrusts smaller things, leaving me to distrust the author’s larger things.

The worst one is "if x=true", which to me says the writer doesn't know what the if statement does...

That said, if x is data read from elsewhere that just happens to be boolean, I can write code like that in Python.

Re: DRY is an over-rated programming principle?

#338

Post by djhaskin987 »

I often find that DRY is in conflict with Conway's law[1]. It's almost always better to let Conway's law win. If I help write a build script for one team, I often copy and paste it into another's git repo to instead of trying to share it. It's often way better than factoring it poorly[2] or getting the two teams to coordinate on changes they need to make to it. Best to let the two copies diverge in that case.

1: https://www.wingolog.org/archives/2015/11/09/embracing-conwa...

2: https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction

Re: DRY is an over-rated programming principle?

#339

Post by gcassie »

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.

Yeah there are a lot of definitions out there that are along these lines and they do hollow out my argument.

But why call it "Don't Repeat Yourself" if it actually means something somewhat more subtle than that. I firmly believe many junior developers don't grasp the nuance and based on the comments I'm not the only one who thinks this. So if DRY is widely understood by developers to mean literally "don't repeat yourself" and nothing more, does it really matter how the formal definition phrases it?

In any event, if SPOT / SST and DRY do mean the exact same thing, I like SPOT / SST better because the names encode the essential concepts of the principle.

Re: DRY is an over-rated programming principle?

#340

Post by cozzyd »

dfee wrote: post #290
lowercased wrote: post #207

Earlier quoted context omitted.

> People not able to factor out functions or structure their code in a readable way. Variables are called v1, v2, v3. Unit testing seen as a waste of time. CI seen as a fun toy. They lack the experience to even notice the difference. Had a colleague work under a 'team lead'. Needed to take a form with variable amount of rows of input data - max 50 - and take data, parse it, and store it. Took 20-30 lines of code. Nex…

I regularly see code of the form `if(x == false)` as the author has a distrust of `if(!x)`. I guess the author just distrusts smaller things, leaving me to distrust the author’s larger things.

In some languages these do different things, right? (Or if someone did something horrendous with operator overloading)
Post reply on HN