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

Re: DRY is an over-rated programming principle?

#311

Post by lamontcg » Thu, Jul 07, 2022, 2:37 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…

with people like that roaming around the landscape maybe there is a point to all that leetcoding nonsense, since they'll certainly spout off some truly insane stuff in interviews...

Re: DRY is an over-rated programming principle?

#312

Post by khalladay » Thu, Jul 07, 2022, 2:37 PM UTC

dfee wrote: post #290

lowercased wrote: post #207

Earlier quoted context omitted.

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

I regularly see code of the form `if(x == false)` as the author has a distrust of `if(!x)`. I guess the author just distrusts smaller things, leaving me to distrust the author’s larger things.

It's been awhile since I absorbed the weird programming norm that "real programmers use the !x form!" but even after 10+ years of !x , I still find ==false more readable.

Re: DRY is an over-rated programming principle?

#313

Post by RajT88 » Thu, Jul 07, 2022, 2:38 PM UTC

Now. I am not a 10x developer.

But this concern here with writing a make_pizza() function:

> The problem is that these two pizzas just happen to have the same crust, sauce and cheese. Had we started out with two pizza types that have different crust/sauce/cheese, we never would have made this refactor.

You can solve for this by adding parameters with default values for all of those things. Use the defaults for the most common use cases, but of course for pizzas with different crusts and such, you can override the default.

Not all languages support default parameter values, it's true. And of course, there is a level of complexity at which this breaks down.

Re: DRY is an over-rated programming principle?

#314

Post by Clubber » Thu, Jul 07, 2022, 2:41 PM UTC

DRY is about code, not data. If you see two methods do the same thing somewhere in their code blocks, separate the duplicate logic into a separate method, then call that method when you need to execute that logic.

The reason for this is maintainability. Say that logic needs to be changed. If you didn't break it out into a callable method, you'd have to find all the places you use that logic and change it. If it is a callable method, you only have to change the logic in one place, thus DRY.

https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

Here is an overly simplistic example:

If you see this scattered around your code:

  var formattedName = firstName + " " + lastName;

Create this method and call it when you need it:

  string FormatName(string firstName, string lastName)
  {
    return firstName + " " + lastName;
  }

  var formattedName = FormatName(firstName, lastName);

When business decides it wants to change name formatting from "firstName lastName" to "lastName, firstName", you only have to change the logic in the FormatName method because you "didn't repeat yourself."

Re: DRY is an over-rated programming principle?

#315

Post by [deleted] » Thu, Jul 07, 2022, 2:43 PM UTC

BigJono wrote: post #143

Ma8ee wrote: post #103

Earlier quoted context omitted.

But that is usually a problem with abstraction, rather than a problem with a method call. If I can trust what make_pizza does, that is much faster to read than any four lines of code. A functional style certainly helps. I get the pizza in my hand and don’t have to worry that anyone left the oven on.

> If I can trust what make_pizza does You can't, unless it's in a standard library or a core dependency used by millions of people. That's one of the reasons why functional code is generally easier to read. A lambda defined a few lines above whatever you're reading gives you the implementation details right there while still abstracting away duplicate code. It's the best of both worlds. People who's idea of "function…

[deleted]

Re: DRY is an over-rated programming principle?

#316

Post by JacobThreeThree » Thu, Jul 07, 2022, 2:45 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…

>Felt like gaslighting, to my recollection.

Sounds like a real-life example of the Asch experiments.

https://en.wikipedia.org/wiki/Asch_conformity_experiments

Re: DRY is an over-rated programming principle?

#317

Post by dragonwriter » Thu, Jul 07, 2022, 2:45 PM UTC

gcassie wrote: post #301

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…

Partially agree. I think SPOT (I'd always heard it called single source of truth) is a more universally applicable paradigm than DRY. Having said that, the cost of creating dependency chains is often underestimated. Overly dogmatic adherence to SPOT/SST can lead you to make the wrong tradeoff on coupling two unrelated areas of your codebase to unify some trivial truth. I'd also say there is a lot of nuance about what…

> I think SPOT (I'd always heard it called single source of truth) is a more universally applicable paradigm than DRY.

“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system” is the verbatim definition of DRY from when the DRY principle was first articulated.

Re: DRY is an over-rated programming principle?

#318

Post by gcassie » Thu, Jul 07, 2022, 2:45 PM UTC

dragonwriter wrote: post #92

> I suspect any developer reading this is aware of the DRY principle because it is just so ubiquitous. If not though, you just need to know that it stands for "Don't Repeat Yourself" and is generally invoked when advising people to not copy and paste snippets of code all over the place and instead consolidate logic into a central place. Well, no. What you actually need to know is the next layer out: DRY stands for Do…

Thanks - I fixed this mistake. I originally was "solving" the problem by checking if the arg passed was a list of lists or a list of strings but I thought I'd get flamed even more for being a terrible developer with that solution.

When you go read proper definitions of DRY they have lots of nuance that speak to many of my criticisms. But the reality is most developers are not encoding that nuance and using it as a fairly blunt instrument. I can't really prove it but at least some people in the comments seem to agree. So I guess I could say "DRY is misunderstood" - but if it's so easily misunderstood then maybe that's a shortcoming in and of itself?

Re: DRY is an over-rated programming principle?

#319

Post by jghn » Thu, Jul 07, 2022, 2:46 PM 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…

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 & cons.

Re: DRY is an over-rated programming principle?

#320

Post by gcassie » Thu, Jul 07, 2022, 2:47 PM UTC

bryanrasmussen wrote: post #64

kaon123 wrote: post #56

I am working in a code base right now that was literally ruined because of #3. It's full of extremely difficult to follow and test higher order functions that are completely unnecessary. A feature request did come for a "half/half" pizza and we're spending our days trying to disentangle the higher order functions. The developer who wrote this thought himself the programmer genius and wanted to make a pattern out of e…

>Argument by Authority may be a fallacy, but it is significantly more persuasive than other arguments. I looked at https://gordonc.bearblog.dev/ - I don't know why I would think this guy was any more of an authority on what was important than I am. So I'm not sure if anyone who thinks they're a programming genius would even care.

I have to agree with you there - I'm just a random guy who wrote a blog post.