One thing to understand is that the examples in books are there to illustrate techniques, not necessarily to show the pinnacle of best practice. So if the sweet spot in refactoring was actually to extract 50-line functions from 500-line functions, every example in the book would take several pages and obscure the actual point.

What matters is not necessarily the size of the example, but that you can see and understand the technique used.

In the specific example, the "print details" comment suggests a smell that can be removed by extracting a print_details() function - better to make the functionality explicit and self-documentating rather than rely on comments.

Unless print_details() had other uses, my personal opinion is that refactoring this would be make-work that takes time away from more important things.

That IS just my opinion : however I'm reading Code Complete at the moment and finding a lot to agree with in it : one point he makes is that studies actually show lower error rates in medium sized functions (50-150 lines) than in either many tiny functions or a few huge functions.

This jives with my own (mainly non-C++) experience though it's at odds with a lot of advice. To see data supporting such large functions is quite a surprise ... "it's not just me then".

Take this too with a pinch of salt :

1. C++ may be different from other languages in optimum function size
2. If your experience suggests a different optimum : 10 or 20 line functions, say, then I wouldn't waste time aggregating them on my or Steve McConnell's say so
3. but I would agree that breaking a 4-line function for the sake of refactoring is unlikely to be worth it (unless each line is very hard to understand!)

One thing to understand is that the examples in books are there to illustrate techniques, not necessarily to show the pinnacle of best practice. So if the sweet spot in refactoring was actually to extract 50-line functions from 500-line functions, every example in the book would take several pages and obscure the actual point.

What matters is not necessarily the size of the example, but that you can see and understand the technique used.

In the specific example, the "print details" comment suggests a smell that can be removed by extracting a print_details() function - better to make the functionality explicit and self-documenting rather than rely on comments.

However, unless print_details() had other uses, my personal opinion is that refactoring this would be make-work that takes time away from more important things.

That IS just my opinion : however I'm reading Code Complete at the moment and finding a lot to agree with in it : one point he makes is that studies actually show lower error rates in medium sized functions (50-150 lines) than in either many tiny functions or a few huge functions.

This jives with my own (mainly non-C++) experience though it's at odds with a lot of advice. To see data supporting such large functions is quite a surprise ... "it's not just me then".

Take this too with a pinch of salt :

1. C++ may be different from other languages in optimum function size
2. If your experience suggests a different optimum : 10 or 20 line functions, say, then I wouldn't waste time aggregating them on my or Steve McConnell's say so
3. but I would agree that breaking a 4-line function for the sake of refactoring is unlikely to be worth it (unless each line is very hard to understand!)