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

421–430 of 501 posts

Re: DRY is an over-rated programming principle?

#421

Post by dragonwriter »

vincnetas wrote: post #226
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…

If you have client and server side and you have to check only in one place if conditions are met, this means that you cant check in client side anything and must do a server call, or implement both server side and client side in single codebase. Not sure if this is always feasible. Add DB to that and this means that you have to always check for constraints at DB level.

> If you have client and server side and you have to check only in one place if conditions are met, this means that you cant check in client side anything and must do a server call, or implement both server side and client side in single codebase

Checks don't have to include the definition of knowledge independently, so multiple checks against the same rule don't need to be a violation. As a simple example, if you have a JSON Schema, that is the single source of truth for validation, and you can validate against it in 16 different places at different stages of processing and you haven't violated the principle that each piece of knowledge should be represented once in a system.

Re: DRY is an over-rated programming principle?

#422

Post by gary_0 »

PathOfEclipse wrote: post #407
gary_0 wrote: post #328

Earlier quoted context omitted.

On a similar note, tree/graph structures should be avoided versus lists unless there is a good reason. Flat is better than nested. A linear block of code is far easier to reason about than a network of function calls, or (heaven forbid) a class hierarchy. Not that such tools don't have their place, but I've seen too much convoluted code that has broken simple things into little interconnected bits for no reason other…

I think this can be generalized even further to the "principle of least power": https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofL... The graph data structure, I believe, is the most generic of data structures, and it can be used to represent any other data structure. This arguably makes it both the most powerful data structure and the, IMO, the one of last resort.

Yes, that's kind of a "fewer moving parts" way of looking at it.

To be clear, I (like the parent post) was using data structures as a metaphor for the organization of source code: "trees" being code that is conceptually like a branching flowchart with many separate nodes, and "lists" being lines of code kept together in one function/class/file (which the parent post points out has the benefit of "locality").

Re: DRY is an over-rated programming principle?

#423

Post by ggregoire »

pech0rin wrote: post #23

Not sure why this is on the frontpage. Not only are there a bunch of typos, a bunch of code doesn't actually work the way they said it does. Also gotta love hating on the 10x developer or whatever for saying you are wrong. EVERYTHING HAS TRADEOFFS. Every single thing has tradeoffs. Obviously you should not write terrible, brittle code. The reason DRY is important is because when you start duplicating code, having 30…

> Not sure why this is on the frontpage.

Not enough people are flagging the post.

Re: DRY is an over-rated programming principle?

#424

Post by dkarl »

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…

> If you have the problem that your coworkers create unnecessary abstractions, I envy you

I'm curious what languages and frameworks you work with. I suspect this is something that varies from one programming subculture to another. In my experience, the only codebases where I've consistently seen underuse of abstraction have been PHP and C, and in those cases it has been because the code was written by entrepreneurs or engineers who were not software professionals. In Java and Scala I've seen plenty of code that used too much abstraction but almost no code that used too little. In C++ and Python I've seen it go both ways.

In my book, what programmers need first of all is the willingness to rewrite their code. I've been trying to hit the right balance for twenty years, but even now I frequently have to backtrack because the decision to add or not add a layer of abstraction turns out to be wrong. Biasing somebody towards or away from abstraction just changes the kinds of mistakes they make without making them better at cleaning them up.

Re: DRY is an over-rated programming principle?

#425

Post by danuker »

scwoodal wrote: post #152
frognumber wrote: post #43

In this case, the problem is with a bug creeping in: crust: "thyn", DRY is about avoiding this class of cut-and-paste bugs too. Or with changing a string to a token, as it should have been: crust: THIN The code isn't even correct. It's mixing JavaScript and Python. I'm also not sure why you'd declare functions for each type of pizza; that's data. I'm not sure about the context, but the right way is: def make_pizza(cr…

Subtle bug in that toppings has a mutable default argument [1]. [1] https://docs.python-guide.org/writing/gotchas/

There is no bug... yet. Unless you modify the default argument.

Sometimes I just want to monkeypatch the list to be immutable in my app.

Re: DRY is an over-rated programming principle?

#426

Post by wruza »

xigoi wrote: post #243
wruza wrote: post #238

Earlier quoted context omitted.

What do you mean? I’m currently using vim-snipmate.

I mean, if you have repetitive pieces of code that can be parametrized, why not parametrize them directly in the code instead of using a tool to produce the same code over and over?

Quoting myself,

due to context switches and parametric entanglement

Re: DRY is an over-rated programming principle?

#427

Post by beyondthebrush »

49531 wrote: post #416

Something I have come to feel myself but haven't found a good way to articulate is asking "is what I am doing favoring authorship over maintenance?". I find that a lot of times the way DRY or other programming principles are used tend to be done to optimize authorship. This optimization sometimes happens at the expense of maintainability. Anticipating maintenance is tricky; I had a scenario where a developer on my te…

I tend to agree with your premise, though I wouldn't say the two are mutually exclusive. In fact, I imagine favoring authorship would more often trend to maintainable code than not, depending on what is being optimized for (writing less code, etc.)

I think in the case you described, instead of handling edge cases within that function, it might have been better to create an entirely new function to be called in those cases. You could then go a step further and identify shared logic, extract those and call them separately. At least that's what I tend to do when I find myself having to branch logic, especially established logic. Obviously I'm assuming a lot of the details here, and most likely what y'all ended up doing was the best right thing for your project/team.

Re: DRY is an over-rated programming principle?

#428

Post by AnimalMuppet »

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…

Every best practice can be overused - used where not needed, used where it doesn't fit, used in trivial cases. And if you've got people who haven't developed sound engineering judgment yet, they'll start by not using those practices. But once you convince them that they should, they'll use them everywhere, even the wrong places.

This is why best practices are needed, and why they are over-rated. Where they are used, they are often over-used.

Re: DRY is an over-rated programming principle?

#429

Post by partdavid »

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…

It also tends to shift the focus, at least in mentally framing the issue, from DRYing out implementations to information. If you're thinking less about implementations (man, I wrote a fold by hand for this thing--maybe I should put all the folds into the same function?) it guards against the "overcomplications" people seem to dislike about DRY. You're thinking more about replacing repeated materializations of the same information with references to a source of truth.

That's why I'm pretty dogmatic in applying DRY to infrastructure as code, for example, as opposed to generically for every code base, because finding or depending on repeated identifiers that have to be the same is such a source of error here.

Re: DRY is an over-rated programming principle?

#430

Post by bstar77 »

Generally, I never think in terms of writing "DRY" code. I think the presumption of re-usability is a primary reason.

I architected a React.js framework that needed to exist in our existing portal environment and play well with all of the other frameworks and scripts. My solution was tightly coupling bundles of code for widgets deployed on my platform. I have conventions all devs need to follow and it does result in not very dry code.

The benefit is that everyone can work independently and not affect each other. Testing is easier to do as there are less logic paths. Performance is still optimized with code-splitting, so the extra code really doesn't affect performance.

Whenever people try to create a DRY one-size-fits-all solution, I find them very inflexible and prone to breaking. Add to that, they are generally poorly documented, so making changes can be very stressful.

Post reply on HN