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

471–480 of 501 posts

Re: DRY is an over-rated programming principle?

#471

Post by kwhitefoot »

fartsucker69 wrote: post #18
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…

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…

> This sounds dumb but it just simply is much harder to keep context about what's going on around if you can't refer back to it because it's on the same screen or one short mouse scroll above or below your current screen.

Are you still using a VT100?

Re: DRY is an over-rated programming principle?

#472

Post by lolc »

sodapopcan wrote: post #440
dfee wrote: post #290

Earlier quoted context omitted.

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.

I've seen this in Ruby and Elixir that drives me a little nuts: if !is_nil(foo)

While it may not matter in many circumstances, this is not the same as "if foo", because false is not nil.

Re: DRY is an over-rated programming principle?

#473

Post by beaker52 »

noisy_boy wrote: post #170
beaker52 wrote: post #42

I once worked on a project that was basically a simple My Account application/area for a train ticket retailer. The backend itself held no data, but whoever built the backend had gone full service layer, with models and adapters to the upstream services that hold the data. The result was a backend that was a pain in the ass to change, necessitating whole trees of file changes to build features. So we started inlining…

> So we started inlining everything. We just took it back to the request handlers. We started fetching, mutating and returning the data in the request handlers. Suddenly a change became modifying one function. Every endpoint was unique and didn't depend on anything else. Things became easy. What is the big benefit you gained from doing that compared to calling, say, a service method call in the controller? costServic…

The most complicated code we had was for generating receipts, which used some functions which we kept separate, because it made sense.

Auth was handled by a middleware. And then once we'd stripped out all the layers, 95% of the handlers looked like roughly like this:

result = fetch(...);

/* Maybe more fetches, maps or filters */

response.send(result);

They didn't really _do_ anything. It was all just small tweaks to data someone else owned. The biggest challenge were upstream endpoints changing on us, making sure we were logging and passing things like correlationIds consistently. Moving to fat handlers, we unified those by having those things already set up and passed into the handlers. The focus was on devex, so a junior could easily modify/create an endpoint and not have to think about how to get it right. We made the pit of success as easy to fall into as possible by breaking the rules that weren't serving the project very well.

It was a glorified proxy layer. There were benefits in treating it as such, rather than deluding ourselves into thinking we needed services, repositories, models and such. Just transform data from someone else's endpoints and focus on the frontend.

Re: DRY is an over-rated programming principle?

#475

Post by godshatter »

khalladay wrote: post #312
dfee wrote: post #290

Earlier quoted context omitted.

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.

It also helps readability if the ! is before a function name that doesn't follow the right naming convention for it. One of my pet peeves in C is "if (!strcmp(a, b))". "!strcmp" I read as "not string compare" and I would expect it to mean that the strings don't compare when it means the exact opposite. This is true of anything following the "0 means success, anything else is an error condition" error handling scheme. So I use "if (strcmp(a, b) == 0)" instead because the "==" makes look at what value it's being compared to specifically and I make fewer assumptions.

Re: DRY is an over-rated programming principle?

#476

Post by im3w1l »

dgb23 wrote: post #209
n4r9 wrote: post #146

Earlier quoted context omitted.

Even better IMO (although devolving into pseudo code): pizza_base = { crust: "thin", sauce: "tomato", cheese: "regular", toppings: [] } hawaiian_pizza = pizza_base { toppings: ["ham", "pineapple"] } pepperoni_pizza = pizza_base { toppings: ["pepperoni"] } def make_pizza(pizza): requests.post(PIZZA_URL, pizza)

Don't do this! OP's version is better! It might be "fine", but you don't gain anything here while introducing both indirection and coupling. DRY is _not_ about data repetition. Data repetition is fine. Alice and Bob having the same birthday is coincidental. And even if they are actually twins, you rather say that they are twins separately. In your example you are just preserving keystrokes, but you don't say anything…

I disagree because his abstraction matches the domain. You will literally see menus designed around the assumption that a not-folded thin (or thick, for some venues I guess) pizza with cheese and tomato sauce is the default, that some pizzas deviate from.

Re: DRY is an over-rated programming principle?

#477

Post by lowercased »

awestroke wrote: post #222
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…

Which country was this in?

US of A.

FWIW this was... 2005-ish.

Re: DRY is an over-rated programming principle?

#478

Post by loudgas »

DougBTX wrote: post #66
bjornsing wrote: post #39

Earlier quoted context omitted.

TLDR: If you do DRY in moderation it’s great (as the OP explicitly says).

What's funny is that DRY was first popularised in the Pragmatic Programmer[0] book, and "coincidental" duplication is explicitly addressed right there on page 34, "not all code duplication is knowledge duplication... the code is the same but the knowledge is different... that's a coincidence, not a duplication." [0] https://www.amazon.co.uk/Pragmatic-Programmer-journey-master...

I believe this was added in the 20th anniversary edition to address the overuse of DRY following the original edition.

Re: DRY is an over-rated programming principle?

#479

Post by Fire-Dragon-DoL »

The big deal is that when a boundary exists, DRY should be "ignored" (cannot word this decently).

For example, let's say there is an application where a user can purchase items and also give reviews for such purchased items, the user reviewing and the user buying have in common just the ID, while in the review boundary the relevant information is probably the user nickname, while in the purchase boundary the relevant information is the payment system, or the state of the checkout ("purchase" is probably not a single boundary).

In that case, data could be duplicated to ensure the boundaries are decoupled.

This is of course at the data level, but usually it translates to "there is a user model that has many orders and many reviews", because of DRY, no two user models could exist, there you have the boundary violation though.

Sorry, this is a bit of a ramble, it's a long discussion.

Re: DRY is an over-rated programming principle?

#480

Post by slowmovintarget »

layer8 wrote: post #418
slowmovintarget wrote: post #325

Earlier quoted context omitted.

And "knowledge" is a far more applicable word than "truth." Truth implies facts, knowledge implies understanding the meaning and associated course of actions. This is the second time in as many days that I've read something purporting to go beyond some original. The one yesterday was "we need more than the four types of documentation." All the examples fit into the four types as originally defined. In HR training, th…

Maybe, but SPOT is a more memorable acronym than SPOK (or whatever). It allows you to talk about the “SPOTs” where stuff is defined. One could also use “SPOTify X” to mean “reducing X to a SPOT”. :)

How about "reduce coupling" in that function, "increase cohesion" in this other function. The DRY principle is intending to get you thinking of coupling and cohesion, which, when gotten backward dramatically increase complexity.

The mechanism to "SPOT that code out, bro!" can be applying varying techniques for reducing coupling, and tightening cohesion. A proper review on a merge request should be making more specific comments about how, not a hand-wave to say "DRY that sucker up."

One final comment: DRY is three characters, therefore obviously more efficient :p

Post reply on HN