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

251–260 of 501 posts

Re: DRY is an over-rated programming principle?

#251

Post by FpUser »

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…

In total agreement. I might have couple of the same snippets of code calculating something in a program and generally would not loose my sleep over it (still will fix it when have nothing else to do). But replicating something like the source of truth is a crime in my book.

Re: DRY is an over-rated programming principle?

#252

Post by Pr0ject217 »

greenthrow wrote: post #218

This post is not very good. DRY is a really solid principle (pun intended.) If you have to define the payload schema for an API yourself (i.e. the API provider doesn't supply a library for you) then you really should define that in one and only one place. It doesn't matter thst today you only want a "handful" of hard coded JSON dicts. That path quickly leads to so many headaches and run time errors. Implementing the…

I'm interested to know more about what you mean in this context by "define the payload schema for the API yourself". Can you provide an example?

Re: DRY is an over-rated programming principle?

#253

Post by usrn »

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…

This is much better although I'd argue even it can be taken too far.

Re: DRY is an over-rated programming principle?

#255

Post by hernantz »

DRY often leads to too much abstraction that while correct from the theory of software engineering, it increases complexity and maintainability costs.

That being said, I always allow myself to repeat code until a good enough patter emerges from that repetition, and then I refactor. Having the same code twice is not always sufficient to reveal what is the right refactor to do, if any.

Re: DRY is an over-rated programming principle?

#256

Post by criddell »

12thwonder wrote: post #194
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?

Some IDEs will warn you about similar blocks of code.

Re: DRY is an over-rated programming principle?

#258

Post by ryathal »

CTmystery wrote: post #249
codesnik wrote: post #206

Earlier quoted context omitted.

I sometimes use term "mid-level engineer syndrome", for "too many levels of abstraction in the codebase". It is very common in my experience. And untangling it's usually harder then extracting common stuff from "dumb" code. I usually don't DRY things up until three repetitions. And in test code - try to not DRY at all, copypaste is a friend of readable and mantainable specs.

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.

Re: DRY is an over-rated programming principle?

#259

Post by Swiffy0 »

ess3 wrote: post #183
Swiffy0 wrote: post #95

Wtf. If your use-case is that the user can select the crust, sauce, cheese and toppings for a pizza, just pass that shit to the make_pizza function with the help of enums and arrays. If you want to have predefined pizzas, you'd simply make a dictionary of pizza templates with all the options that the make_pizza function needs and/or if you wanna be fancy, you'd make a separate make_pizza_from_template function, but d…

> It's not your fault if nobody cared to mention that the user should be able to arbitrarily subdivide the pizza and select options sepatately for each subdivision - that's a feature update and it's OK if the original program hadn't though of that. I would argue it’s part of your job most of the time to challenge whatever needs are presented and ask questions about the long-term vision to find a good middle ground of…

Thought someone might say this!

You're right. At the risk of sounding kind of hypocritical, after a decently long career in software engineering, I've learned that some carefully chosen future proofing is one of the things that makes a great developer and it's also something where one learns to eventually "see" where it is needed.

My "if nobody cared to mention..." part should have probably said "if nobody cared to mention, even after several specification meetings, that the software should be able to do X..." as I agree it's definitely part of your job to assess the needs.

This post is a bit weird though. It's as if someone is ranting about how hard it is to hammer nails into wood with a shoe or 15 other things, when you could just use a hammer.

Post reply on HN