> Functions have names and you get to name the code in a way that shouldn't expire the way comments can.
Sure that's a benefit, but often times I think the scrolling is a downside that is underrated. The code being right in front of you has huge value.
> In most languages separate functions create separate scopes. This prevent incidental use of temporaries from one section into anothe
Right. Thought I mentioned that. That's why I think local functions are good. Gives the best of both worlds. It's a proper name instead of a comment, and gives the right scope.
> but if it becomes part of the public API
Yes obviously API design is a separate (and MUCH) harder question than refactoring for breaking logic apart I think.
> but often times I think the scrolling is a downside that is underrated
What editor can't take you directly to a defined symbol, even ones in other files, nowadays?
As for API design, all classes and functions implicitly become APIs for more abstract code that calls it. Give any surviving piece of enough time and eventually one part of the code with depend on things provides by what logically seems like entirely different parts of the code. At some the team will wonder why these aren't separate libraries (or gems, pips, rocks, packages or whatever), and the API will be whatever the original classes and function were. And if those things were well encapsulate that process might be easy.
This is why least responsibility, DRY and the smallest functions possible are important. Eventually everything will be part of an unbroken stack connecting your users to a CPU and to fix problems in the middle you need simplicity.
Sure that's a benefit, but often times I think the scrolling is a downside that is underrated. The code being right in front of you has huge value.
> In most languages separate functions create separate scopes. This prevent incidental use of temporaries from one section into anothe
Right. Thought I mentioned that. That's why I think local functions are good. Gives the best of both worlds. It's a proper name instead of a comment, and gives the right scope.
> but if it becomes part of the public API
Yes obviously API design is a separate (and MUCH) harder question than refactoring for breaking logic apart I think.