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

Re: DRY is an over-rated programming principle?

#191

Post by theK » Thu, Jul 07, 2022, 11:28 AM UTC

MichaelGlass wrote: post #31

fartsucker69 wrote: post #18

Earlier quoted context omitted.

I don't read coding opinion articles like OP but I like to check out comments. > DRY does NOT lead to over-complicating things. That is not true. I dive around foreign code bases a lot and dry-ness is actually a significant complicating factor in understanding code, because you're jumping around a lot (as in physically to different files or just a few screens away in the same file). As in, inherently every time it's…

Agreed. To use the example from the article `make_pizza(["pepperoni"])` What does `make_pizza()` do? It could be a lot or it could be a little. It could have side-effects or not. Now I have to read another function to understand it, rather than easily skimming the ~four lines of code that I would have to repeat. I think the article fails to show particularly problematic examples of DRY. E.g. merging two ~similar func…

Arguably one could say that this is a typing (as in type system) problem

`makePizza :: PizzaType -> [Toping] -> IO (Pizza)`

Seems to carry all that information by just accepting a PizzaType symbol and a list of toppings, `IO` communicating the side effect.

Re: DRY is an over-rated programming principle?

#192

Post by kitkat_new » Thu, Jul 07, 2022, 11:29 AM UTC

jmartrican wrote: post #147

To help figure out when to DRY or leave wet i like to use the rule of 3. Where a piece of code needs to be repeated 3 times before it is DRYd up. You can adjust this number from 3 to whatever you would like. What I really like about rule of 3, vs rule of 2, is that it allows more time to go by that may lead to the two pieces of code no longer being identical as requirements change. Which would either remove the need…

> Which would either remove the need for the abstraction or allow for a more accurate abstraction.

or indicate a bug or nothing, because the differences aren't in logic, but e.g. in variable names.

^ perhaps voluntarily or, because happen to not find the duplication, or not search it in the first place.

The more time passes by the higher the risk.

Re: DRY is an over-rated programming principle?

#193

Post by rhdunn » Thu, Jul 07, 2022, 11:33 AM UTC

The general approach is to refactor/generalize when creating a third version of something. With the first thing, you don't know if it needs any common functionality or what an appropriate abstraction will look like. With the second thing, you have some similarities but not enough information to know where the abstractions should be -- here, repeating yourself is OK.

With the third thing, you should have enough information to work out where generalizations should be. Even then, only generalize what you need to at the time. Going overboard can add unnecessary complexity, so it is generally a good idea to be conservative in what you generalize.

As you add more things, you can refine and evolve the system as needed. At this time you should have a better understanding of the system and what parts can be shared and generalized.

Re: DRY is an over-rated programming principle?

#194

Post by 12thwonder » Thu, Jul 07, 2022, 11:34 AM UTC

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 like this.

It is very hard to find out if the definition already exists or not in the codebase. This can lead to multiple definitions of the same thing or the truth.

anyone has a good way to deal with this?

Re: DRY is an over-rated programming principle?

#195

Post by QuadmasterXLII » Thu, Jul 07, 2022, 11:34 AM UTC

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…

In my workspace, the issue isn’t that junior developers consistently DRY too much or too little, instead they make dramatic mistakes in both directions. However, the code that repeats itself unnecessarily is way, way easier to fix than the code that tangles itself up like the left pineapple example.

Re: DRY is an over-rated programming principle?

#196

Post by davewritescode » Thu, Jul 07, 2022, 11:38 AM UTC

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…

Your problem isn’t DRY, your problem is that you don’t have people advocating for very basic best practices.

You can’t adopt DRY or SPOT or anything else if you aren’t free to refactor and you aren’t free to refactor without some tests.

Re: DRY is an over-rated programming principle?

#197

Post by valand » Thu, Jul 07, 2022, 11:39 AM UTC

People forget that DRY means "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system".

The principle concerns the duplication of knowledge, not code.

Author's reference to "accidental duplication" is caused by two similar code that represents different code that is when joined becomes the code that is ambiguous in meaning.

Re: DRY is an over-rated programming principle?

#198

Post by battlebeansbogs » Thu, Jul 07, 2022, 11:41 AM UTC

strken wrote: post #97

Surely you'd remove repetition by doing this instead: hawaiian_pizza = { crust: "thin", sauce: "tomato", cheese: "regular", toppings: ["ham", "pineapple"] } pepperoni_pizza = { crust: "thin", sauce: "tomato", cheese: "regular", toppings: ["pepperoni"] } def make_pizza(pizza): requests.post(PIZZA_URL, pizza) This isn't better just because it's DRY, it also keeps the data separate from code, which makes it usable elsew…

Came here for this. Why would your pizza definitions be in code at all.. Python is my favourite language but boy does it make people crazy, imagine recompiling your an app because restaurant A wanted to add a new pizza definition?

To speak to the wider point about DRY, it's a guiding principle for abstraction. If you have two kinds of abtractions for your method, one leads to code repetition, the other does not. Generally favour the does not.

The fact that you should have additional rules, like you shouldn't need rabbit hole debugging (jumping through a million files/objects) to understand core behaviour is not a failure of a useful guiding principle

Re: DRY is an over-rated programming principle?

#199

Post by xigoi » Thu, Jul 07, 2022, 11:43 AM UTC

wruza wrote: post #9

What forced me most to use DRY in inappropriate ways is typing out blocks of the same code again and again. Then I realized that and began to maintain and use easily expandable snippets with fillable placeholders. It turned out that my mind had no objections against repetitive code at all, and the clarity of it has only increased, due to the lack of context switches and parametric entanglement.

Why not turn your snippets into actual templates?

Re: DRY is an over-rated programming principle?

#200

Post by augustk » Thu, Jul 07, 2022, 11:44 AM UTC

wolframhempel wrote: post #98

I think the underlying meta principle here is: Don't be dogmatic in your following of principles. Make sensible choices for the use case at hand which might be informed by the spirit of principles, but don't treat them like some biblical commandment that has to be applied at all time.

  The apprentice doesn't know about it. 
  The journeyman uses it dogmatically.
  The master uses it thoughtfully.