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

281–290 of 501 posts

Re: DRY is an over-rated programming principle?

#281

Post by wizofaus »

runeb wrote: post #274
wizofaus wrote: post #264

Earlier quoted context omitted.

Codegen is great for lots of sync between client and server (I just wish there were more standardized tools), but what if it's a complex algorithm that you need to be able to perform both client and server side, assuming they use different languages?

That's where you need to consider practicality, and it degrades quickly. If it's fairly simple and compartmentalised code without external dependencies like services running on server, you could consider transpiling to target runtimes. But most likely at that stage you'll call a remote function through an API when you need that business logic on the client.

Sure, if performance isn't an issue (e.g. it might need to be done per keystroke). Small amounts of logic duplication like that can be annoying though, esp. when inevitably they end up not agreeing and users don't understand why they're being told their input is invalid. One option I've used is to have the server precompute all possible outputs for all possible inputs, it can work pretty well even with 10s of 1000s of entries.

Re: DRY is an over-rated programming principle?

#282

Post by sjducb »

Pr0ject217 wrote: post #268

What about something like this (in JS)? // Option 1 const Pizzas = { Hawaiian: { type: 'hawaiian', crust: 'thin', sauce: 'tomato', cheese: 'regular', toppings: ['ham', 'pineapple'], }, Pepperoni: { type: 'pepperoni', crust: 'thin', sauce: 'tomato', cheese: 'regular', toppings: ['pepperoni'], }, }; // Option 2 // Pizzas could be returned from an API, so that the pizza types are configurable outside of the code const r…

That's very clever, but the OP's point is that you shouldn't try to be clever. Your life will be easier if the code is simple.

When I read the initial example I can understand it in the time taken to read the code.

With your example I had to think for about 1-2 min before it made sense. If the codebase is full of clever stuff then I have to spend hours understanding all of the clever things before I can make changes. If everything is simple then it's easy to change.

If you want to see where overengineering leads you then take a look at this project. https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

It is satire but I have absolutely worked in places that write code like that.

Good programmers know that it's 10x times harder to read code than write it, so they deliberately keep it simple so that they can read it later.

Re: DRY is an over-rated programming principle?

#283

Post by V-2 »

Valid points, but it doesn't make DRY overrated. Just abused / taken too far if one is overeager. That's true of any principle if you're being dogmatic about it and start treating it as a goal in and of itself (rather than as means towards a goal). This, to me, fits the typical "X considered harmful" (headline) / "X considered harmful when done badly" (actual content) template.

Re: DRY is an over-rated programming principle?

#284

Post by agentultra »

It's worth knowing when it's useful to apply. Needlessly duplicating code also creates another kind of complexity: large surface areas of change that need to be updated in tandem. If you get changes where you have to change multiple places at once in the same way it's a good sign you need to do some refactoring before someone accidentally introduces an error into the program.

Re: DRY is an over-rated programming principle?

#285

Post by DavidSharff »

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…

> Overcomplicating things leads to overcomplicating things.

This would be the most efficient title, subtitle, and entire contents of most posts about programming principles.

However, each reader has to have a similar enough perspective, background, and experience to understand and apply it. In that sense, the trend line measuring the value of commenting about comments about random blog posts indeed indicates wasted time, but hopefully it's a local minima.

My pithy corollary to your helpful tautology is a quote from Tommy Angelo that's stuck with me since my poker days: "The decisions that trouble us most are the ones that matter least."

Decisions are necessarily difficult to make when the expected value of either outcome are similar. We waste an awful lot of time on choices that could have been made just as well with a coin flip.

So there you go world: two quotes that are generally useful about generalities that are locked, loaded, and ready to shoot you in the foot when misapplied.

Edit: formatting improvement.

Re: DRY is an over-rated programming principle?

#286

Post by jjice »

A Philosophy of Software Design by John Ousterhout goes into some of these ideas a bit. To me, the book takes an approach that is somewhat contradictory to Clean Code (a bible to many), but in a rational and well explained way. Lots of talk about over abstraction which can end up complicating code reading in the long run.

An idea I've seen a lot here on HN is that DRY is good with a baseline number of reuse. If we see the same pattern twice, maybe it's not a good abstraction since we haven't seen it grow yet. If we see that same pattern 15 times, I think we know an abstraction is handy here.

Re: DRY is an over-rated programming principle?

#287

Post by rmbyrro »

tpoacher wrote: post #221
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…

Occasionally, it's not clear if a single point of truth is entirely appropriate, or even if it is it can lead to tiresome extra levels of abstraction. In this case, I sometimes prefer a slightly different approach; let's call it CRAP - Cross Reference Against Protocol: instead of definitions effectively referring physically to the same point of truth, they are designed instead such that they simply cross reference ag…

I have a feeling the acronym won't help to push your idea for wide adoption.

Re: DRY is an over-rated programming principle?

#288

Post by Pr0ject217 »

sjducb wrote: post #282
Pr0ject217 wrote: post #268

What about something like this (in JS)? // Option 1 const Pizzas = { Hawaiian: { type: 'hawaiian', crust: 'thin', sauce: 'tomato', cheese: 'regular', toppings: ['ham', 'pineapple'], }, Pepperoni: { type: 'pepperoni', crust: 'thin', sauce: 'tomato', cheese: 'regular', toppings: ['pepperoni'], }, }; // Option 2 // Pizzas could be returned from an API, so that the pizza types are configurable outside of the code const r…

That's very clever, but the OP's point is that you shouldn't try to be clever. Your life will be easier if the code is simple. When I read the initial example I can understand it in the time taken to read the code. With your example I had to think for about 1-2 min before it made sense. If the codebase is full of clever stuff then I have to spend hours understanding all of the clever things before I can make changes.…

Thank you for your response. Would you mind clarifying what is clever about it? Thank you very much.

Re: DRY is an over-rated programming principle?

#289

Post by towaway15463 »

jjice wrote: post #286

A Philosophy of Software Design by John Ousterhout goes into some of these ideas a bit. To me, the book takes an approach that is somewhat contradictory to Clean Code (a bible to many), but in a rational and well explained way. Lots of talk about over abstraction which can end up complicating code reading in the long run. An idea I've seen a lot here on HN is that DRY is good with a baseline number of reuse. If we se…

I believe that’s called WET (Write Everything Twice). It’s a useful reminder to not be dogmatic about DRY.

Re: DRY is an over-rated programming principle?

#290

Post by dfee »

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…

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.

Post reply on HN