4 ms·

> the code can't be read top-to-bottom The idea of the technique is to split out code at a different level of abstraction with a clear name communicating what

> the code can't be read top-to-bottom The idea of the technique is to split out code at a different level of abstraction with a clear name communicating what it does, while hiding the details of the how, because you don't need to care about that detail at all to fully grok the code in the calling function. Where this breaks down is when the code you're trying to split out is not at a different level of abstraction, and how it works is meaningful to the surrounding code in the calling function. So I think the issue you are seeing isn't with the technique, it's with the technique being misapplied. I think this is likely the only difference between when it 'often works' and 'just as often doesn't' in the code you're working in :-)

shellback3 4y ago
I agree, my thoughts were along this line especially when I noticed the 'magic' number -3.
wpietri 4y ago
This is my experience too. I love hiding detail for readability, but you have to hide the right details! It's also definitely related to testability for me. If I'm pulling out the right details, then I'll often get a nice cluster of tests that pin down the higher-level concept in a way where it's both the production and test code that gets more readable.
lamontcg 4y ago
Each function becomes something new that needs to stick in your brain. Someone that applies "MORF" to their code winds up nearly inventing their own language in the file that they're writing. All that takes up more memory when you're reading their code, because due to leaky abstractions the actual implementation of whatever the function name that you replace it with is often important. I have an actual track record of taking code that someone had MORF'd to hell and rewriting it, and making it about 40% shorter, with much fewer concepts to process. Inventing a term like "MORF" is probably illustrative of the problem itself. Without looking at the blog post what exactly was that acronym again? That is just one more thing for you to try to memorize. The author is riffing on things like "DRY" and "YAGNI" that are well-known, but it isn't really helping with readability when you lift it out of that context.
- usrusr 4y ago
  I agree, one of my favorite ide functions is the inline button. Because all too often that supposedly clear name turns out to be not clear at all. Perhaps it would not be quite as bad if there was a clear distinction between "this is a function for reuse" and "this is a function that's naturally just elaborate code folding", but that does not really exist. Just stick to single-assignment variables and keep their scopes short and enjoy the good parts of sequential code.
- majormajor 4y ago
  > All that takes up more memory when you're reading their code, because due to leaky abstractions the actual implementation of whatever the function name that you replace it with is often important. "Better names" is a good answer for a sloppy pattern that looks like this: fun saveRecord(record){ wireRecord = record.toWireRecord(); innerSaveRecord(wireRecord) } fun innerSaveRecord(wireRecord){ log("saving record " + wireRecord) saveWireRecord(wireRecord) } That's a stupid level of nesting instead of a reasonably-named "convertAndLogAndSaveRecord()" - then you get into debates about if logging should be in that name, otherwise it's happening despite the name not saying it, etc. So all that to say that moving into functions alone can be good, or can be bad. The easiest-to-define benefit of the verbosely-named "convertAndLogAndSaveRecord()" is that it becomes easily testable vs having those lines inlined somewhere. (I'm often much more ambivalent on "reuse" benefits - if your function is specific it can't be made reusable without making it less well defined.) But as far as I know, the world doesn't offer me a way to test that the function not only does what it says but doesn't do what it doesn't say. And it's similarly hard to talk other programmers out of shoehorning new logic into existing functions - now making them harder to reason about - rather than new functions that are composed differently or with the existing ones. Because if "checkAccountingProcessResultsAgainstAudit" is going to give you readability benefits, it damn well better do what it says every time you call it instead of becoming a maze of conditionals and optional behavior.
- AnimalMuppet 4y ago
  > Each function becomes something new that needs to stick in your brain. But if you don't put it in a separate function, then all that code becomes something that you have no choice but look at as part of this function, because the text of it is right there in the function. Sticking part of the code in a sub-function gives you the choice: Do I trust that this function does what it says, with no other effects that I have to worry about? Or do I go look at it to make sure? But not sticking the code in a sub-function gives you no choice - it's right there as part of the function you're looking at, and you have to see what that code is doing as part of understanding the function. And having that code not in a separate function makes it more likely that it has side effects that can mess up the rest of the function (separate functions is a firewall against side effects).
kristopolous 4y ago
The problem is those who create the messes to need that advice probably will take that advice and create even bigger messes In practice, pithy adages don't get us any closer to sanity Really the only news you can use is 1. Try to modify things with code you didn't write by not simply throwing parts away 2. If you think it's really difficult to deal with, figure out if other people agree with you. 3. understand why everybody thinks this 4. If you are doing that in your own code, then stop doing that. You have to viscerally understand why a practice is bad and how doing it affects other people. This is how you can intuitively avoid such practices in the future. Not through things that rhyme or acronyms that spell words but through social intelligence. It's fundamentally behavior
danmaz74 4y ago
I understand the idea, but it requires: * great ability at naming methods - which isn't very common * massive discipline at RE-naming methods when they get changed even slightly to do something more Regarding the latter, I've seen so many times methods which originally described what they were doing, but now they don't any more, that I never just trust the name to tell me what a method really does.
- catlifeonmars 4y ago
  Naming is probably the single hardest part of writing scalable, legacy code. Cache invalidation is a cakewalk in comparison. I believe this is in part because naming is a miniature exercise in empathy for future readers particular of a piece of code.

shellback3 4y ago

I agree, my thoughts were along this line especially when I noticed the 'magic' number -3.

wpietri 4y ago

This is my experience too. I love hiding detail for readability, but you have to hide the right details! It's also definitely related to testability for me. If I'm pulling out the right details, then I'll often get a nice cluster of tests that pin down the higher-level concept in a way where it's both the production and test code that gets more readable.

lamontcg 4y ago

Each function becomes something new that needs to stick in your brain. Someone that applies "MORF" to their code winds up nearly inventing their own language in the file that they're writing. All that takes up more memory when you're reading their code, because due to leaky abstractions the actual implementation of whatever the function name that you replace it with is often important. I have an actual track record of taking code that someone had MORF'd to hell and rewriting it, and making it about 40% shorter, with much fewer concepts to process. Inventing a term like "MORF" is probably illustrative of the problem itself. Without looking at the blog post what exactly was that acronym again? That is just one more thing for you to try to memorize. The author is riffing on things like "DRY" and "YAGNI" that are well-known, but it isn't really helping with readability when you lift it out of that context.

usrusr 4y ago
I agree, one of my favorite ide functions is the inline button. Because all too often that supposedly clear name turns out to be not clear at all. Perhaps it would not be quite as bad if there was a clear distinction between "this is a function for reuse" and "this is a function that's naturally just elaborate code folding", but that does not really exist. Just stick to single-assignment variables and keep their scopes short and enjoy the good parts of sequential code.
majormajor 4y ago
> All that takes up more memory when you're reading their code, because due to leaky abstractions the actual implementation of whatever the function name that you replace it with is often important. "Better names" is a good answer for a sloppy pattern that looks like this: fun saveRecord(record){ wireRecord = record.toWireRecord(); innerSaveRecord(wireRecord) } fun innerSaveRecord(wireRecord){ log("saving record " + wireRecord) saveWireRecord(wireRecord) } That's a stupid level of nesting instead of a reasonably-named "convertAndLogAndSaveRecord()" - then you get into debates about if logging should be in that name, otherwise it's happening despite the name not saying it, etc. So all that to say that moving into functions alone can be good, or can be bad. The easiest-to-define benefit of the verbosely-named "convertAndLogAndSaveRecord()" is that it becomes easily testable vs having those lines inlined somewhere. (I'm often much more ambivalent on "reuse" benefits - if your function is specific it can't be made reusable without making it less well defined.) But as far as I know, the world doesn't offer me a way to test that the function not only does what it says but doesn't do what it doesn't say. And it's similarly hard to talk other programmers out of shoehorning new logic into existing functions - now making them harder to reason about - rather than new functions that are composed differently or with the existing ones. Because if "checkAccountingProcessResultsAgainstAudit" is going to give you readability benefits, it damn well better do what it says every time you call it instead of becoming a maze of conditionals and optional behavior.
AnimalMuppet 4y ago
> Each function becomes something new that needs to stick in your brain. But if you don't put it in a separate function, then all that code becomes something that you have no choice but look at as part of this function, because the text of it is right there in the function. Sticking part of the code in a sub-function gives you the choice: Do I trust that this function does what it says, with no other effects that I have to worry about? Or do I go look at it to make sure? But not sticking the code in a sub-function gives you no choice - it's right there as part of the function you're looking at, and you have to see what that code is doing as part of understanding the function. And having that code not in a separate function makes it more likely that it has side effects that can mess up the rest of the function (separate functions is a firewall against side effects).

kristopolous 4y ago

The problem is those who create the messes to need that advice probably will take that advice and create even bigger messes In practice, pithy adages don't get us any closer to sanity Really the only news you can use is 1. Try to modify things with code you didn't write by not simply throwing parts away 2. If you think it's really difficult to deal with, figure out if other people agree with you. 3. understand why everybody thinks this 4. If you are doing that in your own code, then stop doing that. You have to viscerally understand why a practice is bad and how doing it affects other people. This is how you can intuitively avoid such practices in the future. Not through things that rhyme or acronyms that spell words but through social intelligence. It's fundamentally behavior

danmaz74 4y ago

I understand the idea, but it requires: * great ability at naming methods - which isn't very common * massive discipline at RE-naming methods when they get changed even slightly to do something more Regarding the latter, I've seen so many times methods which originally described what they were doing, but now they don't any more, that I never just trust the name to tell me what a method really does.

catlifeonmars 4y ago
Naming is probably the single hardest part of writing scalable, legacy code. Cache invalidation is a cakewalk in comparison. I believe this is in part because naming is a miniature exercise in empathy for future readers particular of a piece of code.