4 ms·
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
by 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 agoThose 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 agoI'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.