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

231–240 of 501 posts

Re: DRY is an over-rated programming principle?

#231

Post by kareemsabri »

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…

In places I've worked DRY is overused, or used poorly. I can't count the number of times you get "DRY" on a code review just cause something appears twice. It's probably because it's the easiest one to spot.

> learning the acronyms like DRY, and just following them

Following DRY is the hard part. As the author points out, to DRY something up you need to pick the right level of abstraction. This requires experience to do well.

Re: DRY is an over-rated programming principle?

#232

Post by runeb »

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.

You could consider codegen from the single point of truth. Not always practical, but great when its set up with good ergonomics.

Re: DRY is an over-rated programming principle?

#233

Post by grog454 »

bjornsing wrote: post #51
MichaelGlass wrote: post #31

Earlier quoted context omitted.

Agreed. To use the example from the article `make_pizza(["pepperoni"])` What does `make_pizza()` do? It could be a lot or it could be a little. It could have side-effects or not. Now I have to read another function to understand it, rather than easily skimming the ~four lines of code that I would have to repeat. I think the article fails to show particularly problematic examples of DRY. E.g. merging two ~similar func…

Yup. But I guess that typically happens in steps. So next DRY-programmer that comes along will add a cheezeFilledCrust boolean to that make_pizza function and so on. Every time it will seem more reasonable to add another boolean, because otherwise you have to remove the make_pizza function, and there would be SO MUCH CODE DUPLICATION. I’ve seen this again and again in the field and I wholeheartedly agree with the sen…

Some languages handle massive parameter lists better than other (ex with defaults). There are also design patterns for this type of problem (ex a PizzaBuilder).

Re: DRY is an over-rated programming principle?

#235

Post by civilized »

We could move away from prescriptive "programming principles" and towards ideas that empower people to use their own judgment. Instead of "Don't Repeat Yourself", it could be "You Don't Have to Repeat Yourself".

Now I know what I'm getting myself into here. Most people hate making their own choices and love to blindly follow simple prescriptive rules which are known by Experts to produce Good Results. But when the religious approach isn't working for you, maybe it's time to stop making your occupation a religion.

Re: DRY is an over-rated programming principle?

#236

Post by civilized »

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…

> Mistake 1: Switch from DRY to premature optimization.

Fallacy: False Dichotomy and No True Scotsman.

"Things are either DRY or premature optimization and can't be both"

"No TRUE application of DRY would ever be a premature optimization"

Re: DRY is an over-rated programming principle?

#237

Post by layer8 »

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.

One way to do this is to have a formal data schema as a separate artifact, which you then have as a dependency in your server and client projects, and generate the checks from the schema, as well as the SQL DDL.

But yes, if you have truly separate codebases it becomes more difficult, and protocols need to be quite stable and changes to them carefully managed.

Re: DRY is an over-rated programming principle?

#238

Post by wruza »

xigoi wrote: post #199
wruza wrote: post #9

What forced me most to use DRY in inappropriate ways is typing out blocks of the same code again and again. Then I realized that and began to maintain and use easily expandable snippets with fillable placeholders. It turned out that my mind had no objections against repetitive code at all, and the clarity of it has only increased, due to the lack of context switches and parametric entanglement.

Why not turn your snippets into actual templates?

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

Re: DRY is an over-rated programming principle?

#239

Post by ergonaught »

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…

That's terrible.

I was in a situation in the early 2000s where the team that would maintain our application after we were gone (to another project or product or company) were not skilled enough to follow certain things, and we were asked to change a number of things to make it easier for them. In that case, the leader of their team was self-aware and honest and communicative, which is the rare and exotic thing, but we did have to re-architect some things and even change the programming language in one area to suit their capabilities. Sometimes that's a business need, and it matters.

Post reply on HN