3 ms·

There are several advantages you are disregarding. Functions have names and you get to name the code in a way that shouldn't expire the way comments can. In m

by sqeaky 9y ago

There are several advantages you are disregarding. Functions have names and you get to name the code in a way that shouldn't expire the way comments can. In most languages separate functions create separate scopes. This prevent incidental use of temporaries from one section into another. Having a smaller scope to look at means that refactoring or changes to new business requirements can have a smaller place for side effects to occur. I agree that testing each part on its isn't required, but if it becomes part of the public API and A is setup database connection and C is teardown Database connection and B is use the database connection then as one function B is really hard to test. Breaking it into three functions lets you write unit tests for at least B by mocking A and C.

alkonaut 9y ago
> 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.
- sqeaky 9y ago
  > 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.

by sqeaky 9y ago

alkonaut 9y ago

> 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.

sqeaky 9y ago
> 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.