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

441–450 of 501 posts

Re: DRY is an over-rated programming principle?

#441

Post by azov »

This is like saying "database normal forms are overrated - they make my SQL more complex and harder to read!"

Well, yes, they do. They also make your database slower. This doesn't mean they are overrated - this means they are tradeoffs. Like everything engineering.

With DB normal forms you buy integrity (i.e. keeping the data consistent as it changes) and you pay with performance and schema complexity. Usually this is a sensible tradeoff because integrity is more important. But, for example, if your data never changes - you will be paying for nothing. Or, perhaps, you can't afford the performance price and you have some other way to ensure integrity. Then you de-normalize.

DRY is similar. As mentioned in the sibling thread, it's not about mechanically avoiding repeated code - just like normal forms are not about never having the same value in two different rows. It's about maintining logical integrity of your code as it changes. PI=3.14159265359? Probably safe to copy around. An implementation of some use case? Probably not.

I'd say following DRY/STEP principle is a sensible default. If a reviewer asks you why your code is not DRY - you should be able to articulate a reason.

Re: DRY is an over-rated programming principle?

#442

Post by recursive »

dfee wrote: post #290
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…

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 wrote code like that sometimes. Equaling false is more specific, depending on language. There are many falsey things that are not false themselves.

Re: DRY is an over-rated programming principle?

#443

Post by linknoid »

mcbutterbunz wrote: post #387
khalladay wrote: post #312

Earlier quoted context omitted.

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.

I agree. To me, its simpler to understand. Suppose x is a bool, reading the code, I say to myself "if not true..." or "if not false..." and my ape brain gets confused on what happens if its not true or not false. Reading "if true == false" or "if false == false", it becomes much clearer what we're testing here and I understand it instantly.

If the statement is "if (!isGreen)", it's much clearer to say "if is not green" than it is to say "if is green is false". Putting == true or == false makes you convert a clear statement "is green" into "true" or "false" instead of just being a natural English statement. It would be like saying in conversation, "I want to go to the store is false" instead of "I don't want to go to the store".

Re: DRY is an over-rated programming principle?

#444

Post by mmcnl »

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…

I half agree here. Especially in Python applications, so often you so a class that is instantiated only once. I'm not sure if this is overly usage of OOP or DRY, but defining a whole class just to be instantiated once seems like a very verbose abstraction to me. There's nothing wrong with a few functions to group code together and leave it at that.

Re: DRY is an over-rated programming principle?

#445

Post by Ma8ee »

BigJono wrote: post #143
Ma8ee wrote: post #103

Earlier quoted context omitted.

But that is usually a problem with abstraction, rather than a problem with a method call. If I can trust what make_pizza does, that is much faster to read than any four lines of code. A functional style certainly helps. I get the pizza in my hand and don’t have to worry that anyone left the oven on.

> If I can trust what make_pizza does You can't, unless it's in a standard library or a core dependency used by millions of people. That's one of the reasons why functional code is generally easier to read. A lambda defined a few lines above whatever you're reading gives you the implementation details right there while still abstracting away duplicate code. It's the best of both worlds. People who's idea of "function…

> If I can trust what make_pizza does

>> You can't, unless it's in a standard library or a core dependency used by millions of people.

You can if you have reasonably competent colleagues. And if you do make some wrong assumptions about what a certain method does, it should be caught by your tests.

I feel that people that insist on reading and understanding all the code, and write code that has to be read fully to be possible to understand what is does, have missed something quite fundamental about software development.

Re: DRY is an over-rated programming principle?

#446

Post by mmcnl »

dfee wrote: post #290
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…

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.

!x is not equal to === false.

Re: DRY is an over-rated programming principle?

#447

Post by xigoi »

wruza wrote: post #426
xigoi wrote: post #243

Earlier quoted context omitted.

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

Can you give an example where abstraction would be too complex, but a snippet wouldn't?

Re: DRY is an over-rated programming principle?

#448

Post by xorcist »

saltsucker wrote: post #388
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'm not sure I follow... Can you provide an example? (junior dev here) If I understand some of it correctly, I was contemplating this when I started writing functions for "single functional concepts" like, "check for X; return true or false", then called each of those functions sequentially in a single "run" function. Is that what you mean? I found that approach much easier to test the functions and catch bugs, but y…

> then called each of those functions sequentially in a single "run" function

If a lot of conditions are checked sequentially, why not write down exactly that? The sequence itself may well be what a reader would like to know.

The one benefit of the added function calls would be that the definition order does not need to change even if there are future changes to the execution order. But that is exactly also what adds mental overhead for the reader.

If the names add context, then that's a perfect use for comments.

Re: DRY is an over-rated programming principle?

#449

Post by bigtunacan »

988747 wrote: post #377
bigtunacan wrote: post #370

Earlier quoted context omitted.

It's not usually needed (especially these days), but there are times that it is better to repeat every possible iteration by hand and not have a loop. This is a technique called loop unrolling. It is done for performance reasons. This is something we used to do at a company working on games for the old feature phones (think Nokia 30/40/60 series stuff). The devices were very limited, there is no direct control over J…

Loop unrolling seems like something that should be done by a compiler when you turn on aggressive optimization flags, and not something you need to code explicitly.

That is why I said it's usually not needed, "especially these days". This was not true at the time. Relying on primitive compilers, especially the likes of the J2ME garbage collection would lead to total freezes in a game from something as simple as a loop. As the garbage collector decides previous passes in the loop are no longer needed it can trigger a garbage collection sweep. With such a slow and limited device a garbage collection sweep would literally cause a game to freeze until the sweep completed which could take on the order of several seconds.

The loop unrolling was just one example of how we would go about preventing an undesirable sweep.

As another example a large global game object array would be created when a game was started. As objects were created and deleted they would really just update pre-created objects in that array.

This allowed us to prevent garbage collection, while simultaneously making sure we didn't run out of memory.

The Nokia 1618 (a series 40 device) has a heap limit of 1024KB. Many S20 and S30 devices were even further memory constrained.

Re: DRY is an over-rated programming principle?

#450

Post by wizofaus »

ickyforce wrote: post #310
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.

This is completely another level of "issues" than other problems in this thread. During code review I'd only mention it as a nit. The longer form is correct and the only downside is that's a bit longer. It doesn't mess up code modularity or affect maintainability in a noticeable way. Well, assuming that the language doesn't have any quirks in this area - e.g. in Java your statements aren't equivalent for a Boolean x.

They're not equivalent in many languages (JS, C++/swift with operator overloads, if x is nullable etc. etc.).
Post reply on HN