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

461–470 of 501 posts

Re: DRY is an over-rated programming principle?

#461

Post by hinkley »

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…

While it is a little easier to deal with flat data than tree data, the real test of this comes when you process the data.

Trees invite recursion, and as the logic grows telling what is going on gets more and more difficult. While it's easier to process trees recursively, it is possible to iterate over it. It's easier to process lists iteratively, but it is possible to handle them recursively. Some people do, much to the detriment of all of their coworkers.

I'm trying to unwind some filthy recursive code on a side project at work. There were two bugs I knew about going in, and two more have been found since, while removing mutually recursive code in favor of self recursion, and then modifying that to iteration.

Iteration is much, much easier to scale to add additional concerns. Dramatically so when in a CD environment where a change or addition needs to be launched darkly. Lists can help, especially with how carefully you have to watch the code. They're not the only solution, they're just the easiest one to explain without offering a demonstration.

Re: DRY is an over-rated programming principle?

#462

Post by fuzzy2 »

icedchai wrote: post #270
fuzzy2 wrote: post #61

I like DRY. Do Repeat Yourself. You can always refactor later, once the requirement/change is fully implemented.

Repeating yourself 3 or 4 times is okay. After that, it is probably worth cleaning up.

Hm, I don’t think it’s about the number of repetitions. Even two can be too much if it’s the same logic, not just coincidentally. The same logic may not always be a code clone either. Maybe you need to generalize the code to remove the repetition.

The reverse is also true: If it’s not the same logic, it should not be deduplicated. Even if it is a code clone now. It will probably lead to unintended bugs down the line when that code changes.

Re: DRY is an over-rated programming principle?

#463

Post by galaxyLogic »

layer8 wrote: post #406
cogman10 wrote: post #376

Earlier quoted context omitted.

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…

Right. There are also "forces" like management who want the project to be finished yesterday.

Another metaphor I like for programming is Chess. Any line you add to the program constrains its future development, becomes "weight" or "force" that pulls your development into some direction. Sometimes you have to sacrifice features like pawns. Sometimes you may sacrifice security, you may think it is secure enough. The outcome of this game is often a draw, or stalemate. And the same game can continue for years.

Re: DRY is an over-rated programming principle?

#464

Post by ozim »

kitkat_new wrote: post #185
ozim wrote: post #141

Earlier quoted context omitted.

How often do you really write the same piece of business logic code in multiple places? I think discussion is that mostly it really is different code that only superficially looks the same. I don't like pizza example. But I have seen more issues because people were trying to cram code that looks the same in one function than some bug needed to be fixed multiple times because code was duplicated. You also have layers…

> How often do you really write the same piece of business logic code in multiple places? well, depends if you avoid DRY or not. If you apply DRY, zero times.

Think again.

Read with understanding.

What is really the question that is asked?

Re: DRY is an over-rated programming principle?

#465

Post by sirmarksalot »

ryathal wrote: post #258
CTmystery wrote: post #249

Earlier quoted context omitted.

You're almost there, IMO. This internet stranger encourages you to ditch the rule of DRYing based on the number of repetitions at all , and instead think of DRYing based on what deserves to change to together. Sometimes a single repetition in code deserves to be DRY. Sometimes 10 repetitions don't deserve to be DRY.

Isn't that playing a little loose with definitions? if you have 10 "repetitions" that don't need to change simultaneously they aren't really repetitions in the first place. Just because a dumb analyzer says you have a 10 line block of identical code in 10 places doesn't mean it's actually identical.

You're restating the article's point. Naive DRY says make the dumb analyzer happy by abstracting out the coincidental similarities. If you work in a place that recognizes that this can be a red herring, then great, but a lot of developers and teams don't make room for that nuance. That is what the article is arguing against.

Re: DRY is an over-rated programming principle?

#466

Post by klik99 »

I’ve had success with WET - write everything twice. If you copy paste something three times it’s a good candidate for abstraction. Ultimately these are just rules of thumb and none will fit all cases. I just found DRY to be too aggressive in practice.

Re: DRY is an over-rated programming principle?

#467

Post by avgcorrection »

svieira wrote: post #303
bjornsing wrote: post #51

Earlier quoted context omitted.

Yup. But I guess that typically happens in steps. So next DRY-programmer that comes along will add a cheezeFilledCrust boolean to that make_pizza function and so on. Every time it will seem more reasonable to add another boolean, because otherwise you have to remove the make_pizza function, and there would be SO MUCH CODE DUPLICATION. I’ve seen this again and again in the field and I wholeheartedly agree with the sen…

This is discussed in detail in "The Wrong Abstraction" by Sandi Metz https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction Quote follows: ---- The strength of the reaction made me realize just how widespread and intractable the "wrong abstraction" problem is. I started asking questions and came to see the following pattern: 1. Programmer A sees duplication. 2. Programmer A extracts duplication and gives it a nam…

Not really a sunk cost fallacy. Existing code needs to be maintained. Some of it should be deleted since it costs more to maintain. Some of it shouldn’t be deleted since it might bite you in the behind when you realize that all of that code was correct (although gnarly) and now you’ve introduced regressions. And which code is which? Hard to say.

Sunk cost (fallacy) is about making decisions based on things that you have already lost. But you haven’t lost or expended the code—the code is right there, and it’s hard to know if it’s more of an asset or a burden.

Re: DRY is an over-rated programming principle?

#468

Post by kcartlidge »

linknoid wrote: post #443
mcbutterbunz wrote: post #387

Earlier quoted context omitted.

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.

If the statement is "if (!isGreen)", it's much clearer to say "if is not green" than it is to say "if is green is false". Putting == true or == false makes you convert a clear statement "is green" into "true" or "false" instead of just being a natural English statement. It would be like saying in conversation, "I want to go to the store is false" instead of "I don't want to go to the store".

> If the statement is "if (!isGreen)", it's much clearer to say "if is not green" than it is to say "if is green is false"

I agree that when you read it, it's clearer. And yet I still prefer "if(isGreen == false)" for reasons of clarity in another sense.

The "!" being right next to the "(" makes it easier to miss the "!" when scanning quickly through the code, hence reading the logic the wrong way round and seeing "(isGreen" instead of "(!isGreen". And that's enough of a risk to ignore the readability advantage of "(!".

(Edit: To be clear, I don't suggest "== true" for the opposite cases, as the lack of a "!" in those means the risk is gone)

Re: DRY is an over-rated programming principle?

#469

Post by SomeCallMeTim »

mavu wrote: post #13

> Instead of our code being architected around the concept of how pizzas are made in the abstract, its architecture is tightly coupled to the specific needs of these two pizzas that we happened to be dealing with. The chance that we will be putting this code back the way it was is extremely high. Mistake 1: Switch from DRY to premature optimization. > You might think that legit reasonable developers but would not act…

Article tl;dr: Design is hard and can't be boiled down into applying pithy mindlessly.

For what it's worth, I agree with your points and disagree with the various counterpoints that were posted; "optimization" can mean a lot of things, and I for one understand what you mean.

Re: DRY is an over-rated programming principle?

#470

Post by inlined »

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…

Also, these are principles, not compiler errors. These principles will complete and it sometimes helps to have an order of precedence. The number one rule is KISS and would have trumped all the examples in the article.

Nit: the article’s problems also have an obvious solution—named parameters with default values when not provided.

Post reply on HN