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

391–400 of 501 posts

Re: DRY is an over-rated programming principle?

#391

Post by saltsucker »

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 am a CS graduate working at a top HW company and you could not have stated it more perfectly. The code I have to work with given to me written by HW engineers is pretty brutal. Talking 1k+ lines of code with 5+ nested conditions on the reg. Ofc, no unit tests. Blows my mind.

Re: DRY is an over-rated programming principle?

#392

Post by dkersten »

No, it’s a pretty good principle, but just like everything in programming, there are no hard rules. Every principle has times when they are appropriate and when they aren’t and it’s our job to find what is most appropriate for the situation at hand. It’s still worth striving towards DRY, but that doesn’t mean that there aren’t many cases where it doesn’t improve the code.

The examples are also pretty contrived, there’s hardly any duplication there and the duplication is very simple and unlikely to change much. DRY is beneficial when the repeated code is complex and will likely need to be changed in the future (eg to fix bugs or to be extended), where repeating the code will be a source of error since every change would then need to be applied to each instance and forgetting one is a problem. The example is trivial enough that I wouldn’t bother refactoring it until it became complex enough to be a problem.

A good principle is to not apply principles too quickly/soon but only when not doing so would introduce complexity or cognitive overhead. YAGNI, basically.

Re: DRY is an over-rated programming principle?

#394

Post by baobabKoodaa »

michaelcampbell wrote: post #299
scambier wrote: post #278

Earlier quoted context omitted.

I have colleagues that take DRY to an extreme when it comes to tests. There are so many levels of abstractions that it's incomprehensible. Tests should be clear and readable, you shouldn't have to dig code to understand _what_ a test is doing.

Tests in particular SHOULDN'T be DRY, IMO. They need to be very much independently modifiable quickly; they're meant to be quirky end-runs around your bespoke, artisinal architecture to get at all the interesting bits. Repetition there is fine.

A downside of this approach is that sometimes when you make a small implementation change, you need to rewrite 50 unit tests.

Re: DRY is an over-rated programming principle?

#395

Post by bcrosby95 »

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…

I usually say: if things tend to change together, then they should be closer together.

This is also why using layers as your primary method of organization is usually a bad decision. You're taking things that change together and strewing them about in different top level directories.

Re: DRY is an over-rated programming principle?

#396

Post by anarazel »

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 the very least it's a signal to hurriedly look for a new job, if not resign on the spot.

Re: DRY is an over-rated programming principle?

#397

Post by BlargMcLarg »

saltsucker wrote: post #388
gary_0 wrote: post #328

Earlier quoted context omitted.

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

Disclaimer, it's mostly a personal thing.

Dividing things into methods mostly gives the benefit of naming and reuse. If you can skip the method's content and reasonably assume it works in some way, it can make reading easier.

If the reader instead feels inclined to read it, they now have to keep context of what they read, jump to the function (which is at a different position), then read the content of the function, then jump back while keeping the information of the function in mind. In bad cases, this can mean the reader has to keep flipping from A to B and back multiple times as they gain more understanding or forget an important detail.

The same thing happens with dividing things up in multiple classes. Don't need to read other classes? Great. Do need to read other classes? Now you have to change navigation to not only vertical, but horizontal as well (multiple files). Some people struggle with it, some people hate it, other people prefer it.

You're basically making a guess what's best in this scenario, and there isn't a silver bullet. The extreme examples are easy to rationalize why they are bad. The cases closer to the middle, not so much.

Re: DRY is an over-rated programming principle?

#398

Post by WorldMaker »

wizofaus wrote: post #264
runeb wrote: post #232

Earlier quoted context omitted.

You could consider codegen from the single point of truth. Not always practical, but great when its set up with good ergonomics.

Codegen is great for lots of sync between client and server (I just wish there were more standardized tools), but what if it's a complex algorithm that you need to be able to perform both client and server side, assuming they use different languages?

You've answered one of the easiest ways to do it: just use the same language. Node (and Deno/Bun) is a good way to maximize code sharing and single points of truth.

But I definitely understand not everyone wants to write all of their backend in JS (or even TS). (Node ORMs sometimes don't have the polish of their cousins in other languages, for instance.)

There are great opportunities here for language mixing, however, in writing that complex algorithm in the same language for both frontend and backend but the rest of the codebases may not be in the same language.

1. V8/JavaScriptCore/SpiderMonkey are all very easy to rehost as "scripting languages" inside many languages people prefer to use on the backend. It's often easy to find wrappers to call JS scripts and marshal back out their results inside the backend language of your choice these days. You pay for transitions to/from JS to your primary backend language, of course, so it takes careful management to make sure these "business rules in JS scripts" aren't in any hotpaths, but a backend may have the cycles for that anyway.

2. WASM is offering more opportunities to bring some of your preferred backend language to the frontend. You probably don't want to write your whole frontend in WASM still today, as WASM still doesn't have the same DOM access, but using WASM for single point of truth business rules has gotten quite viable. You still pay for the startup costs and marshalling costs between JS and WASM, but in many cases that's all still less than network call. (I'm still skeptical of tools like Blazor for .NET, especially those building full frontends with it, but I definitely appreciate that reach of "write once" business logic for both client and server.)

Re: DRY is an over-rated programming principle?

#399

Post by bcrosby95 »

michaelcampbell wrote: post #299
scambier wrote: post #278

Earlier quoted context omitted.

I have colleagues that take DRY to an extreme when it comes to tests. There are so many levels of abstractions that it's incomprehensible. Tests should be clear and readable, you shouldn't have to dig code to understand _what_ a test is doing.

Tests in particular SHOULDN'T be DRY, IMO. They need to be very much independently modifiable quickly; they're meant to be quirky end-runs around your bespoke, artisinal architecture to get at all the interesting bits. Repetition there is fine.

I dunno. I think a few helper methods helps a lot in tests - like if you have a common operation in the setup portion. I don't think the code needs to be super abstract, but it shouldn't all be hand typed out.

Re: DRY is an over-rated programming principle?

#400

Post by AnimalMuppet »

BurningFrog wrote: post #329
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…

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

Especially for an object that has to have some consistency between its members, all the code that has to maintain that consistency (or that can break the consistency, same thing) should be in the same place - functions of that class. So if you ever see a class that has the data in an inconsistent state, you have a very small set of places to look for the culprit.
Post reply on HN