5 ms·

in the example given, I started with 10 things to keep in working memory. now that we've added a named function or a named variable, we have 11. I suggest it

in the example given, I started with 10 things to keep in working memory. now that we've added a named function or a named variable, we have 11. I suggest it is at least as important to name things well (or add comments) as it is to break lines up.

Wowfunhappy 4y ago
A nice feature of working memory is that although it's limited to around 6† "things", each thing can be any size, if your brain considers it a single unit. This is called "chunking". So, it's easier to remember the three numbers 34, 765, 812 than the eight numbers 3, 4, 7, 6, 5, 8, 1, 2. Refactoring code into separate functions with descriptive titles is probably a lot like combining numbers. --- † Well, the article says 4–6; I'd always heard the average was around 7.
pavon 4y ago
I'm working on a project that is following Uncle Bob's Clean Code guidelines of striving to having functions be ideally 3 lines or less, and nor more than say 7. I have mixed feelings about it. My initial prejudices have largely held. I do find the code harder to read and follow. Having to jump around, follow variables that change name as they are passed through functions, keeping track of state that was moved to a class member rather than in a function body (because breaking into pure functions resulted in too many function parameters). I can't fit as much code on screen because of all the additional function definitions. Lastly, the success of the method relies heavily on how well you name your functions, which is often considered one of the hardest parts of programming. A name that makes perfect sense to me may not be as clear to others, or even to myself in two months. And the devil is in the details - there are so many implied semantic preconditions and postconditions with every function you write, there is no way to fit that into a function signature no matter how well chosen, and if you tried to document them them all your comments would be larger than code itself at this level of granularity. So you still end up having to read all the called code to understand the details of what is happening anyway, which is easier to do with more flat code. On the other hand, I've found the process of "extract till you drop" to be very helpful in forcing me to find ways to clean up my code. It naturally tends towards maintaining separation of concerns, finding ways to DRY when the initial structure wasn't conducive to it, and generally disentangling things even more so than when I try to refactor to meet these goals directly. If I had all the time in the world on other projects, I think I would apply "extract till you drop" on my code, then after it is disentangled, recombine it back into reasonable size chunks.
- hardware2win 4y ago
  >guidelines of striving to having functions be ideally 3 lines or less, and nor more than say 7. I have mixed feelings about it. Dont feel bad about it Those small functions with hard limits are just terrible advice When you gotta know functions impl., which for me is very often Then this approach just increases cognitive load
  - f1shy 4y ago
    Those guidelines should (my personal position) be taken as advisory, and never as hard rules. Functions should be “small enough, that a less than gifted can understand it”. Is difficult to measure in lines. Best example is a big switch with 10 cases. Artificially breaking that in smaller pieces is not helpful. I have a soft rule of 3 to 7 different control structures (if, for, case, etc) in total, and 2 or 3 nested.
  - retrocryptid 4y ago
    I'm not going to disagree completely with @pavon. He's stating his lived experience and I respect that. Maybe people are different in this regard. I'm more in line w/ @hardware2win. More smaller functions just seem to add to the cognitive load. But I am a fan of cascading a bunch of message sends / method invocations. I've never had a problem with that. People seem to be passionate about their answers, now I want to get the programmer psychology book and see if there's data about people being more effective with or without a lot of small functions.
artemonster 4y ago
You forgot a KEY property of a function: this is an abstraction. You don't (and in most cases shouldn't) care how this "black box" does what it does, you identify it by the name and move on. So a function collapses N things to understand to 1, not how you have described it.
- f1shy 4y ago
  Exactly. At each level of abstraction, you don’t care what the functions look inside. The name must be enough to understand what it does. You can of course descend one level, but at that point the layer above is no important. Just that the function fills the contract, possibly calling. Still more functions, which at that level are black boxes…

Wowfunhappy 4y ago

A nice feature of working memory is that although it's limited to around 6† "things", each thing can be any size, if your brain considers it a single unit. This is called "chunking". So, it's easier to remember the three numbers 34, 765, 812 than the eight numbers 3, 4, 7, 6, 5, 8, 1, 2. Refactoring code into separate functions with descriptive titles is probably a lot like combining numbers. --- † Well, the article says 4–6; I'd always heard the average was around 7.

pavon 4y ago

I'm working on a project that is following Uncle Bob's Clean Code guidelines of striving to having functions be ideally 3 lines or less, and nor more than say 7. I have mixed feelings about it. My initial prejudices have largely held. I do find the code harder to read and follow. Having to jump around, follow variables that change name as they are passed through functions, keeping track of state that was moved to a class member rather than in a function body (because breaking into pure functions resulted in too many function parameters). I can't fit as much code on screen because of all the additional function definitions. Lastly, the success of the method relies heavily on how well you name your functions, which is often considered one of the hardest parts of programming. A name that makes perfect sense to me may not be as clear to others, or even to myself in two months. And the devil is in the details - there are so many implied semantic preconditions and postconditions with every function you write, there is no way to fit that into a function signature no matter how well chosen, and if you tried to document them them all your comments would be larger than code itself at this level of granularity. So you still end up having to read all the called code to understand the details of what is happening anyway, which is easier to do with more flat code. On the other hand, I've found the process of "extract till you drop" to be very helpful in forcing me to find ways to clean up my code. It naturally tends towards maintaining separation of concerns, finding ways to DRY when the initial structure wasn't conducive to it, and generally disentangling things even more so than when I try to refactor to meet these goals directly. If I had all the time in the world on other projects, I think I would apply "extract till you drop" on my code, then after it is disentangled, recombine it back into reasonable size chunks.

hardware2win 4y ago
>guidelines of striving to having functions be ideally 3 lines or less, and nor more than say 7. I have mixed feelings about it. Dont feel bad about it Those small functions with hard limits are just terrible advice When you gotta know functions impl., which for me is very often Then this approach just increases cognitive load
- f1shy 4y ago
  Those guidelines should (my personal position) be taken as advisory, and never as hard rules. Functions should be “small enough, that a less than gifted can understand it”. Is difficult to measure in lines. Best example is a big switch with 10 cases. Artificially breaking that in smaller pieces is not helpful. I have a soft rule of 3 to 7 different control structures (if, for, case, etc) in total, and 2 or 3 nested.
- retrocryptid 4y ago
  I'm not going to disagree completely with @pavon. He's stating his lived experience and I respect that. Maybe people are different in this regard. I'm more in line w/ @hardware2win. More smaller functions just seem to add to the cognitive load. But I am a fan of cascading a bunch of message sends / method invocations. I've never had a problem with that. People seem to be passionate about their answers, now I want to get the programmer psychology book and see if there's data about people being more effective with or without a lot of small functions.

artemonster 4y ago

You forgot a KEY property of a function: this is an abstraction. You don't (and in most cases shouldn't) care how this "black box" does what it does, you identify it by the name and move on. So a function collapses N things to understand to 1, not how you have described it.

f1shy 4y ago
Exactly. At each level of abstraction, you don’t care what the functions look inside. The name must be enough to understand what it does. You can of course descend one level, but at that point the layer above is no important. Just that the function fills the contract, possibly calling. Still more functions, which at that level are black boxes…