[strict9]

>“Don’t Repeat Yourself” often gets interpreted as “Don’t Copy Paste” or to avoid repeating code within the codebase

When I think of the most difficult to understand code I've come across it was probably written by someone who lives and breathes that interpretation of DRY.

But it doesn't end with code comprehension. Extreme abstraction and countless files and components also lead to buggy and difficult to maintain code.

It's easy to lose understanding of branches and business flow when abstraction exists in the extreme.

[andorov]

DRY needs to be balanced with SRP (Single Responsibility Principle). You can legitimately have two functions that are exactly the same but they should not be DRY'd up if they are actually serving different purposes.

The use cases will likely diverge in the future, and if the functions are DRY'd making changes will make introducing bugs from the calling code that you're not working on easy. Eventually the single function will likely have a lot of conditions in it, which is a red flag for this situation.

[ramesh31]

>You can legitimately have two functions that are exactly the same but they should not be DRY'd up if they are actually serving different purposes.

I use what I've come to call the "Rule of Three" here.

The first time, don't even consider any kind of abstraction. Just do the thing.

The second time, don't abstract yet. Repeat yourself, but do it in a way that will scale and make abstraction possible, while mentally noting how you might abstract it.

The third time, abstract it.

Adhering to this, the vast majority of code will never reach that third stage, thus taming the complexity beast.

[javajosh]

I do something similar, but not as precisely specified as this. But I like it.

It's similar to my own rule about when to add a tool. I wait until I'm doing something else and I feel the lack of that specific tool. The first time, it's on my radar. The second time, it's time to get the tool. If you get it on first impulse, you'll drown in tools (and won't give the tools you have a fair shake). If you wait too long, you'll acclimate to not using the proper tool.

[mewpmewp2]

I use the rule of "Annoyance". When I get annoyed by having to rewrite what already exists, I'll try to make it DRY, or when I have to fix things in multiple places many times.

I outsource a lot of decisions to that feeling, so I can focus on other things.

It's a matter of time anyway when it's really easy to ask ChatGPT to refactor everything into this perfect code.

[kitkat_new]

> Adhering to this, the vast majority of code will never reach that third stage, thus taming the complexity beast.

yeah, because you probably forgot about at least one of the other repetitions somewhere in the code

as a developer you should know if it makes sense or not

[evntdrvn]

I call it WET, “Write Everything Twice”. It’s catchy enough that people remember/follow it, esp with the antonym making it memorable :)

[getoffmycase]

Thanks for putting the process of what I did twice in the last two days into clear, coherent words and logic.

[pydry]

I usually phrase this as balancing against loose coupling.

I've had bad experiences with the single responsibility principle. It sounds kind of right, but in practice "responsibility" is too vague and often surprisingly hard to agree on what is e.g. one responsibility vs. three responsibilities.

By contrast, loose coupling is more objective and can (at least in theory) be measured.

[Spivak]

I call these frankenframeworks. The constant drive to DRY and reach the supposed nirvana of code being a DSL of pure business logic leads to more and more implementation details being shoved under the rug to deeper and deeper layers. But for some reason there’s no foresight that any non-trivial change requires changing more than just the business logic and so you have to resort to bolting on config options, weird hooks, mixins, “concerns”, and global state for no reason other than it’s all you can do to reach down the layers.

[qudat]

> When I think of the most difficult to understand code I've come across it was probably written by someone who lives and breathes that interpretation of DRY.

Totally agree with this interpretation and why I wrote a recent article about it: https://bower.sh/anti-pattern

[strict9]

Great article, particularly agree with the tests part. Sanity check tests (function doesn't throw an exception in common path) are essential but following all possible paths and verifying all outputs is the road to diminishing returns and subpar output.

[unethical_ban]

Back when I took a Comp sci course 16 years ago (shit) I was taught that a single function should try to fit within a screen. The idea is that breaking a task up into digestible steps would both harbor more readable code, self-documentation and code reuse.

[MrPatan]

Good idea, wrong metric. What should fit in a screen is the concept. If you take a big, hairy, complicated thing and just chop it into several functions that fit on a screen you have gained nothing.

[saulpw]

If you name the functions reasonably, and the functions don't interact except through arguments and return values, you have absolutely gained something.

[commandersaki]

Probably a good case for inclining: http://number-none.com/blow/blog/programming/2014/09/26/carm...

[thfuran]

Inlining is the compiler's job, not mine.

[commandersaki]

You probably should read the article as Carmack makes the case for inlining as a style, not inlining as an optimisation.

[rzzzt]

That's when you rotate the display to vertical orientation.

[justinator]

"big, hairy, complicated thing" is a code smell and you would consider doing something about it, before it becomes truly a monster. Breaking it up into its constituent parts may be the way to go, if only because my brain's CPU cache is about 8 bytes of faulty memory.

[mcphage]

> The idea is that breaking a task up into digestible steps would both harbor more readable code, self-documentation and code reuse.

Sometimes. Other times it means you need to jump around in a file (or jump between files, even) to understand what's going on.

[wizofaus]

Which is fine - any software of non-trivial complexity is going to require looking at the behaviour of multiple execution units, which may well be in different files. But if they're named sensibly and the dependencies are clearly maintained, the typical programmer is going to have a much easier time of "understand[ing] what's going on" than a single huge largely-unstructured blob of code. The moment you can't quickly see where a block starts and ends (without using IDE shortcuts) then the code has a readability issue.

[vlunkr]

I've dealt with code like that, and often wrote it. It's incredibly hard to get right IMO. It's an intuition that you develop over years of trial and error, not an exact science or set of rules.

[rpastuszak]

> When I think of the most difficult to understand code I've come across it was probably written by someone who lives and breathes that interpretation of DRY.

Good code rhymes! It's better to err on the side of less abstraction and create patterns that will become familiar to the next person working with your code.

Reading code is harder than writing it and most of the time coding is about communicating with humans or "ghosts", i.e. people you might never meet, people who worked on the code in a different context or "era".

https://sonnet.io/posts/code-sober-debug-drunk/

https://sonnet.io/posts/emotive-conjugation/#:~:text=Ghost%2...