DRY is an over-rated programming principle? • Hacker News Board

Re: DRY is an over-rated programming principle?

#361

Post by gspencley » Thu, Jul 07, 2022, 3:35 PM UTC

Translation: I took DRY in isolation, never learned larger architectural concepts like SOLID, things that change together live together, loose coupling. Didn't really study up on code smells and their solutions. Didn't learn design patterns and the problems they are designed to solve. Then I ran into trouble and now I blame DRY.

The point of DRY is that when you need to change something, you should only have to change it once (a common code smell that comes about when not employing DRY is "Shotgun Surgery"). If the rest of your architecture is broken, DRY is not going to magically save it. That should be obvious.

Re: DRY is an over-rated programming principle?

#362

Post by n4r9 » Thu, Jul 07, 2022, 3:36 PM UTC

dgb23 wrote: post #209

n4r9 wrote: post #146

Earlier quoted context omitted.

Even better IMO (although devolving into pseudo code): pizza_base = { crust: "thin", sauce: "tomato", cheese: "regular", toppings: [] } hawaiian_pizza = pizza_base { toppings: ["ham", "pineapple"] } pepperoni_pizza = pizza_base { toppings: ["pepperoni"] } def make_pizza(pizza): requests.post(PIZZA_URL, pizza)

Don't do this! OP's version is better! It might be "fine", but you don't gain anything here while introducing both indirection and coupling. DRY is _not_ about data repetition. Data repetition is fine. Alice and Bob having the same birthday is coincidental. And even if they are actually twins, you rather say that they are twins separately. In your example you are just preserving keystrokes, but you don't say anything…

With only 2 types of pizza with the same base, I'm inclined to agree. But if there are more, or a strong potential for more (as there is with pizza), I'd argue that this factoring allows simpler implementation of new pizzas as well as easier comparison of existing pizzas.

Re: DRY is an over-rated programming principle?

#363

Post by dan_83 » Thu, Jul 07, 2022, 3:37 PM UTC

Looks like a perfect case for a builder pattern, that way you can support sensible defaults in just about every language.

default_pizza() .with_crust(Crust::Cheesy) .with_sauce(Sauce::Garlic) .add_topping(Topping::ExtraCheese) .cook()

I'm not going to weigh in on the DRY stuff because it's being discussed to death. I just liked thinking about how I would approach this problem.

Re: DRY is an over-rated programming principle?

#364

Post by dkottow » Thu, Jul 07, 2022, 3:43 PM UTC

DRY is mostly fine in code, but does not hold for data. There, inmutability and audit trails win over DRY, in my opinion.

Re: DRY is an over-rated programming principle?

#365

Post by ParetoOptimal » Thu, Jul 07, 2022, 3:47 PM UTC

gcassie wrote: post #307

gjulianm wrote: post #100

Earlier quoted context omitted.

I think that drawing conclusions from these examples is not productive at all. In the wild we're going to see functions such as def make_string_filename(s): # four lines of regex and replace magic so that we have code like file_src = make_string_filename(object_name) file_dst = make_string_filename(object_name_2) which is much more understandable than eight lines of regex magic where you don't even know what the rege…

That's fair. But maybe someone wants to reuse this in another place so they do this: ``` def make_string_filename(s, style="new"): # 2 lines of shared magic if style == "old" # 2 lines of original magic elif style == "new": # different 2 lines of magic ``` When you get here, two totally separate `make_string_filenames()`, each private to the area of code they're relevant to, would be better.

The ideal is having 3 functions I think:

- make_string_filename_style1

- make_string_filename_style2

- make_string_filename

Then make_string_filename consists of logic to use the right style.

Or one function and a Sum type to be called like:

    makeStringFilename Style1 "somestring"

Given sum type:

    data FilenameStringStyles = Style1 | Style2

Re: DRY is an over-rated programming principle?

#366

Post by whatsakandr » Thu, Jul 07, 2022, 3:49 PM UTC

He doesn't address the problem of in a large project, sometimes it's better to copy and paste a function to avoid the extra library dependency. DRY and over coupling are two forces that must be balanced by the engineer. Dry is more important at small scales, over coupling is more important at large scales.

Re: DRY is an over-rated programming principle?

#367

Post by ess3 » Thu, Jul 07, 2022, 3:49 PM UTC

Swiffy0 wrote: post #259

ess3 wrote: post #183

Earlier quoted context omitted.

> It's not your fault if nobody cared to mention that the user should be able to arbitrarily subdivide the pizza and select options sepatately for each subdivision - that's a feature update and it's OK if the original program hadn't though of that. I would argue it’s part of your job most of the time to challenge whatever needs are presented and ask questions about the long-term vision to find a good middle ground of…

Thought someone might say this! You're right. At the risk of sounding kind of hypocritical, after a decently long career in software engineering, I've learned that some carefully chosen future proofing is one of the things that makes a great developer and it's also something where one learns to eventually "see" where it is needed. My "if nobody cared to mention..." part should have probably said "if nobody cared to m…

100% agree, both on your points and the article lacking a point.

Re: DRY is an over-rated programming principle?

#368

Post by atx42 » Thu, Jul 07, 2022, 3:51 PM UTC

On the other hand, I find most frameworks don't allow for DRY. The typical case is making a 40 char DB field, and then having to code a check in the payload to ensure field is 40 chars. I've wondered if any system has achieved such enlightenment.

Re: DRY is an over-rated programming principle?

#369

Post by sime2009 » Thu, Jul 07, 2022, 3:52 PM UTC

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…

A closely related rule of thumb for organising code is: "Things which change together, belong together."

Re: DRY is an over-rated programming principle?

#370

Post by bigtunacan » Thu, Jul 07, 2022, 3:54 PM UTC

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…

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 J2ME garbage collection, etc... so loops could very noticeably slow down games.

We initially wrote code with loops, then would performance test and manually unroll when it was necessary. Eventually this became very burdensome and we eventually... wrote code to unroll the loops for us and that code of course had loops in it because it was build code that wouldn't ship.

There are other performance situations where this technique applies.

This may not have been the situation there, but I think it's important that rather than assume stupidity from the outside that we try to ask why.