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

401–410 of 501 posts

Re: DRY is an over-rated programming principle?

#401

Post by WorldMaker »

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.

I'm a big proponent for the "rule of [at least] three" for building DRY abstractions: once is YAGNI (you aren't going to need it), twice is coincidence, three is finally a pattern emerging.

Re: DRY is an over-rated programming principle?

#402

Post by 8note »

Notably, this already starts dry.

A less dry one would look like

def make_hawaiian_pizza(): payload = { hwaiianCrust: "thin", redSauce: "tomato", cheese: "regular", ham: true, pineapple: true, toppings: ["ham"] } requests.post(PIZZA_URL, payload)

def make_pepperoni_pizza(): payload = { pepperoniCrust: "thin", crust: "thick", sauce: "tomato", cheese: "regular", toppings: ["pepperoni"] } requests.post(PIZZA_URL, payload)

Re: DRY is an over-rated programming principle?

#403

Post by surement »

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…

> But most places I have worked, these best practices were not overused, but underused

For what it's worth, 90% of the code bases I've worked on overused DRY. Two pieces of code that do the same thing but that shouldn't be coupled should be repeated, otherwise you end up with a million "if" statements for all the separate cases this code will need to handle as it grows, as well as uncertainty about whether changes will have unintended consequences.

Re: DRY is an over-rated programming principle?

#406

Post by layer8 »

cogman10 wrote: post #376
galaxyLogic wrote: post #348

Earlier quoted context omitted.

I think the rule should be "Try not to repeat yourself" Rules are like alarms they draw our attention to some peculiar condition which gives us pause to think about if it's kosher and if not why not.

The art of programming is finding the fit and exceptions to the rules. It's just, frankly, a lot easier to be dogmatic. Someone says "never do this" or "always do that" and you can apply those rules with abandon (often leaving a maintenance nightmare in your wake). There are no rules to programming.

I find it useful to think of it as forces pulling on the design, similar to physical forces acting on an object. There are forces that try to keep individual truths/knowledge and responsibilities in a singular place, there are forces that try to minimize abstractions, coupling, dependencies, and indirections, there are forces that try to maximize coherence and separation of concerns, and so on. It’s an essential part of the job of a software engineer to balance those adequately in the design of the software.

Re: DRY is an over-rated programming principle?

#407

Post by PathOfEclipse »

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 think this can be generalized even further to the "principle of least power": https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofL...

The graph data structure, I believe, is the most generic of data structures, and it can be used to represent any other data structure. This arguably makes it both the most powerful data structure and the, IMO, the one of last resort.

Re: DRY is an over-rated programming principle?

#408

Post by layer8 »

jghn wrote: post #319
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…

One underappreciated hard bit of SPOT is knowing for sure that something does in fact represent the same truth. One of the pain points of the DRY/SPOT model occurs when a new use case arrives that breaks existing truths for certain subcomponents. It can be real painful to decouple things. This is not a reason to avoid SPOT altogether, but one think through that situation as part of their mental calculus on pros & con…

It’s difficult to discuss this in the abstract, but one benefit of SPOT is that it tells you which code (the users of the SPOT) you have to consider when decoupling/refactoring. In contrast, when it’s decoupled in the first place, but actually represents the same truth, you may have no idea that the other instances exist.

Writing code such that it’s reasonably easy to decouple or recombine existing uses is mostly orthogonal, I think. Usually you can just duplicate whatever is at the SPOT when the need for more than one truth arises.

Re: DRY is an over-rated programming principle?

#409

Post by chrismarlow9 »

philliphaydon wrote: post #124
nicbou wrote: post #94

Earlier quoted context omitted.

This works until someone updates code in one place, but not the other, and subtle bugs are introduced. DRY / single source of truth offers a certain protection against such bugs.

Only experience teaches you where to apply DRY and where not to. Sometimes just because something looks the same or is similar does not mean it’s the same. Applying DRY just because it looks the same can have the unwanted consequence of changing in 1 place changing in another too when that’s not the desired affect. Then you add another parameter and conditional logic just because you don’t want 2 similar looking thin…

Out of all the comments on this post, this is the one I agree with the most. I have been bitten by "not enough DRY" as well as "too much DRY".

I think experience as well as the maturity of the code are most relevant when deciding things like this. If you do this too early you will back yourself into a corner or eventually end up with a "god function" (usually the outcome of what OP mentions about conditional logic and more params).

If you wait too late you will inevitably have a giant codebase with lots of duplicates everywhere.

In my experience it's easier to clean up duplicated code than it is to break apart a "master function" that nobody has touched in 3 years out of fear.

Re: DRY is an over-rated programming principle?

#410

Post by marcosdumay »

vincnetas wrote: post #226
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…

If you have client and server side and you have to check only in one place if conditions are met, this means that you cant check in client side anything and must do a server call, or implement both server side and client side in single codebase. Not sure if this is always feasible. Add DB to that and this means that you have to always check for constraints at DB level.

> this means that you cant check in client side anything and must do a server call, or implement both server side and client side in single codebase

Or you derive one of the implementations from the other, or both from a third one.

But yeah, heterogeneous environments have a tendency of creating unnecessary code duplication.

Post reply on HN