This is why I think it's a mistake that many popular languages, including standard c/c++, do not support nested function definitions. This for me is the happy medium where code can be broken into clear chunks, but cannot be called outside of the intended scope. A good compiler can also detect if the nested function is only called once and inline it.

C++ has lambdas and local classes. Local classes have some annoying arbitrary limitations, but they are otherwise useful.

After spending a lot of time writing idiomatic React components in es6, I've found my love of locally declared lambdas to really grow. If I give the lambdas really good names, I find that the main body of my component is very, very readable, even more so than if I'd used a more traditional style liberally sprinkled with comments.

> If I give the lambdas really good names

That's a really funny way to say it.

Giving your lambdas names defeats part of their purpose though.

They have two distinct purposes: anonymous functions, and closures. Those often go together, but there are many scenarios where you only care about the latter, and don't actually need the former. Named lambdas (i.e. lambdas assigned to local consts) covers this case if the language doesn't have dedicated syntax for it.

maybe one purpose. but it fulfills another purpose- self-documenting code, and a really simple non-nested main body to your function.

In Java, a local function reference (defined inside a method and never used outside of this method ) is possible. Notre that this function is not really tied to an object, which is why I don't call it a method, and I don't use the expression "method reference", it is just tired to the function that contains it, which may be a method - or not.

Code can always be called outside of that scope just by returning function pointers or closures. The point is not to restrict calling that code, but to restrict the ability to refer to that piece of code by name.

As mentioned by others, C++ has lambdas. Even if you don't use lambdas, people used to achieve the same effect by using plenty of private functions inside classes, even though the class might have zero variables and simply holds functions. In even older C code, people are used to making one separate .c file for each public function and then define plenty of static functions within each file.

Of course all this needs to be weighed against maintainability and readability of the code. If the code base is not mainly about something very performance critical and this kind of thing shows to be a bottleneck, then changing things away from more readable towards performance optimized implementation would require a very good justification. I doubt, that this kind of optimization is justified in most cases. For that reason I find the wording "prematurely breaking out code" to be misleading. In most cases one should probably prioritize readability and maintainability and if breaking code out helps those, then it cannot be premature. It could only be premature from a performance limited perspective, which might have not much to do with the use case/purpose of the code.

It is nice, if a performance optimization manages to keep the same degree of readability and maintainability. Those concerns covered, sure we should go ahead and make the performance optimization.

What I'm advocating here is only coincidentally a performance optimization. Readability and maintainability (and improved abstraction) are the primary concern and benefit of (sometimes) keeping things inline or more specifically of reducing entropy.

Here is a followup post for those interested: https://benoitessiambre.com/integration.html