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.

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.

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.

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

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

Inlining is the compiler's job, not mine.

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

I did read the article. I think I'm less in favor of that style than he is (or at least was), but even he said that the problems it addresses arise from subroutines not being pure functions and so isn't a proponent of it in the case the comment you replied to was describing. And when not writing in that style, inlining is for the compiler to do.

The original poster said if you chop a big hairy complicated thing into functions to fit on a screen you've gained nothing. The response is that if they're named reasonably and pure then you have.

Now the reason I posted that inlining article from Carmack leans heavily into this line of advice: "if a function is only called from a single place, consider inlining it."

Taking a complicated mess and breaking it into functions that are called from a single place seems better served by organising the code (maybe with duplication if needed) and writing inline comments rather than devoting a call tree to that section of code.

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

"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.

> 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.

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.

> 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

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.

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.

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.

>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.

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

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.

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.

> 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

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

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.

> 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...