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

381–390 of 501 posts

Re: DRY is an over-rated programming principle?

#381

Post by harry-wood »

michaelcampbell wrote: post #296
nevinera wrote: post #242

Earlier quoted context omitted.

In rails shops, "dry" is _always_ overused. It was part of the red->green cycle in TDD culture, and got mentioned in every context, and as a result nearly all legacy rails apps are filled with weird abstractions introduced in a commit with a message like "dry it up". The problem is that it's phrased as a rule rather than a smell. DRY deserves to be listed with other code smells that may indicate a missing abstraction…

Thanks; this is about what I was going to say but you said it better. DRY is a tool, not a design goal. I think part of the Rails issue is a combination of the early Rails hype/philosophy, and the fact that DRY as a concept is so easy to "get", that everyone gets it but often fail the next step of "why". Without the why, you often can't figure out the right when/where so it gets applied everywhere. It feels to me lik…

But "early Rails hype/philosophy" is the only thing you've said specifically about Rails. I think I know what you mean though. There are strong philosophies in the Rails (and more generally ruby) communities. Opinionated coding, and software craftsmanship is lauded, more than in other language communities I think.

As a result, rules of thumb like DRY are drummed into new developers. The overall effect of that is probably better code quality in general, but yes probably more instances of them being over-used.

But if Rails has the problem of folks over-using DRY, what are other languages communities doing? Just not doing so well at telling people about DRY in the first place?

Re: DRY is an over-rated programming principle?

#382

Post by theptip »

My personal rule of thumb for this type of situation is to use the counting scheme “one, two, many” and to try to defer commonizing before you get to “many” instances of the repeating pattern.

It’s really easy to make assumptions about what you are going to need later that turn out to be completely unfounded (or even - years later there is no “many”, just the one or two usages you already have).

And I think folks shouldn’t freak out over a little bit of duplication, as long as it doesn’t get out of hand in the codebase, and you make sure to come back to refactor later when you do have many common usecases.

Re: DRY is an over-rated programming principle?

#384

Post by theptip »

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…

Yep, it’s a general gripe with thought-pieces; advice is context dependent.

Or, put differently, my HN motto: don’t give uni-directional advice when optimizing a U-shaped error function.

Re: DRY is an over-rated programming principle?

#386

Post by HWR_14 »

988747 wrote: post #377
bigtunacan wrote: post #370

Earlier quoted context omitted.

It's not usually needed (especially these days), but there are times that it is better to repeat every possible iteration by hand and not have a loop. This is a technique called loop unrolling. It is done for performance reasons. This is something we used to do at a company working on games for the old feature phones (think Nokia 30/40/60 series stuff). The devices were very limited, there is no direct control over J…

Loop unrolling seems like something that should be done by a compiler when you turn on aggressive optimization flags, and not something you need to code explicitly.

Now, that's probably true. However, in the days of feature phones compilers auto optimization were still inferior to a person unrolling a loop in ASM.

Re: DRY is an over-rated programming principle?

#387

Post by mcbutterbunz »

khalladay wrote: post #312
dfee wrote: post #290

Earlier quoted context omitted.

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.

It's been awhile since I absorbed the weird programming norm that "real programmers use the !x form!" but even after 10+ years of !x , I still find ==false more readable.

I agree. To me, its simpler to understand. Suppose x is a bool, reading the code, I say to myself "if not true..." or "if not false..." and my ape brain gets confused on what happens if its not true or not false.

Reading "if true == false" or "if false == false", it becomes much clearer what we're testing here and I understand it instantly.

Re: DRY is an over-rated programming principle?

#388

Post by saltsucker »

gary_0 wrote: post #328
epage wrote: post #220

Earlier quoted context omitted.

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…

I'm not sure I follow... Can you provide an example? (junior dev here)

If I understand some of it correctly, I was contemplating this when I started writing functions for "single functional concepts" like, "check for X; return true or false", then called each of those functions sequentially in a single "run" function. Is that what you mean?

I found that approach much easier to test the functions and catch bugs, but your comment seems to go against that.

Post reply on HN