6 ms·

>“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 unde

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

Spivak 4y ago
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.
unethical_ban 4y ago
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 4y ago
  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 4y ago
    If you name the functions reasonably, and the functions don't interact except through arguments and return values, you have absolutely gained something.
    - commandersaki 4y ago
      Probably a good case for inclining: http://number-none.com/blow/blog/programming/2014/09/26/carmack-on-inlined-code.html http://number-none.com/blow/blog/programming/2014/09/26/carm...
      - thfuran 4y ago
        Inlining is the compiler's job, not mine.
        commandersaki 4y ago
        You probably should read the article as Carmack makes the case for inlining as a style, not inlining as an optimisation.
        thfuran 4y ago
        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.
        commandersaki 4y ago
        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.
  - rzzzt 4y ago
    That's when you rotate the display to vertical orientation.
  - justinator 4y ago
    "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 4y ago
  > 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 4y ago
    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.
qudat 4y ago
> 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 https://bower.sh/anti-pattern
- strict9 4y ago
  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.
andorov 4y ago
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.
- pydry 4y ago
  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.
- ramesh31 4y ago
  >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.
  - getoffmycase 4y ago
    Thanks for putting the process of what I did twice in the last two days into clear, coherent words and logic.
  - javajosh 4y ago
    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.
vlunkr 4y ago
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 4y ago
> 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/code-sober-debug-drunk/ https://sonnet.io/posts/emotive-conjugation/#:~:text=Ghost%20in%20the%20/bin/sh https://sonnet.io/posts/emotive-conjugation/#:~:text=Ghost%2...

Spivak 4y ago

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.

unethical_ban 4y ago

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 4y ago
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 4y ago
  If you name the functions reasonably, and the functions don't interact except through arguments and return values, you have absolutely gained something.
  - commandersaki 4y ago
    Probably a good case for inclining: http://number-none.com/blow/blog/programming/2014/09/26/carmack-on-inlined-code.html http://number-none.com/blow/blog/programming/2014/09/26/carm...
    - thfuran 4y ago
      Inlining is the compiler's job, not mine.
      - commandersaki 4y ago
        You probably should read the article as Carmack makes the case for inlining as a style, not inlining as an optimisation.
        thfuran 4y ago
        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.
        commandersaki 4y ago
        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.
- rzzzt 4y ago
  That's when you rotate the display to vertical orientation.
- justinator 4y ago
  "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 4y ago
> 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 4y ago
  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.

qudat 4y ago

> 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 https://bower.sh/anti-pattern

strict9 4y ago
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.

andorov 4y ago

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.

pydry 4y ago
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.
ramesh31 4y ago
>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.
- getoffmycase 4y ago
  Thanks for putting the process of what I did twice in the last two days into clear, coherent words and logic.
- javajosh 4y ago
  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.

vlunkr 4y ago

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 4y ago

> 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/code-sober-debug-drunk/ https://sonnet.io/posts/emotive-conjugation/#:~:text=Ghost%20in%20the%20/bin/sh https://sonnet.io/posts/emotive-conjugation/#:~:text=Ghost%2...