4 ms·

Yes, yes! Having to locate and dig through 10+ different smaller functions that are called within another function is much harder to troubleshoot and work with.

by 20years 10y ago

Yes, yes! Having to locate and dig through 10+ different smaller functions that are called within another function is much harder to troubleshoot and work with. Especially when 95% of those are not re-used anywhere else. I know it may not be the popular belief but I would much rather work with a larger well written 50 line function that does what it is supposed to do vs having to navigate around a bunch of smaller 5 line functions that are never re-used anywhere else.

collyw 10y ago
Me too.
Roboprog 10y ago
We need to not work on the same project :-)
potatoyogurt 10y ago
If it's done right, though, you shouldn't have to navigate around all the smaller 5 line functions, at least not unless you're debugging. Each of the submethods should clearly describe what it does, and do that without any unexpected side-effects or implicit state changes. Effectively, what this does is raise the level of abstraction of the code, so that your 50-line function becomes a 10-line function, and you only need to read those 10 lines to understand what's going on. Sometimes when you're debugging, you might need to dip into these subfunctions, but when you do, you should be able to think through them as mostly independent units that just need to do what their name says they will do. This ideally limits the problem of having to load everything that your code is doing into your head all at once in order to reason through it. When you're just reading through the code normally, you should be able to gloss over the details of how the submethods work, just as you probably wouldn't feel compelled to dig into the internals of how a library call like Collections.sort works. The problem is that method decomposition is not always done well, and when there is unexpected behavior or implicit state changes, it can make bad code even harder to navigate. I'd also rather read a well-written 50 line function than a poorly decomposed cluster of 10-line functions. With proper care, though, method decomposition is super helpful.
- 20years 10y ago
  "The problem is that method decomposition is not always done well" Yeah :(
- sbov 10y ago
  Part of the problem is that the abstraction of "a sorted list" will never change. But the abstraction of "twiddle my foobar" can change on a weekly basis based upon business needs. Because of this the abstractions we write will never be as strong or enduring as those found in the standard library.
  - potatoyogurt 10y ago
    Certainly true, but that's not a reason to give up on creating those abstractions, like the post I was replying to was suggesting. It's a reason to be judicious about when it's appropriate to create these abstractions, and in particular about when they should be shared. An abstraction that's used in just one or two places is still really easy to change. A bad abstraction used in a dozen places is a pain the ass to clean up. It's not an easy problem, and it ultimately takes some combination of experience and careful mentoring to learn to identify good and bad abstractions before they're built.
- sheepmullet 10y ago
  That's the theory. In practice it is difficult to get the right level of abstraction. This is why writing a good library often takes 3x as much effort as writing the equivalent application code.
  - tigershark 10y ago
    This only means that you are not putting enough effort when writing your application code compared to the library. So you are basically adding technical debt to your application. Apart from a deadline that will make the project fail if it is missed I don't see any rational reason to add technical debt. And also in that case you must plan some time to remove the technical debt that you just introduced, and better sooner than later. So writing a library is not harder than writing a good application. It is certainly harder than writing quickly a mess of hacks that become an application.
BWStearns 10y ago
Part of that can also be that the helper functions are taking in whole objects (think js mvc style model objects) when they're really doing a date calculation on one field in the objects. It's not bad that the logic is encapsulated, it's that its encapsulated at the wrong layer. I've run across well written 50 line functions in Perl or c# but I would hesitate to call a function in js or other potentially more concise languages well written (discounting lines devoted to object/dict/hash definitions).

by 20years 10y ago

collyw 10y ago

Me too.

Roboprog 10y ago

We need to not work on the same project :-)

potatoyogurt 10y ago

If it's done right, though, you shouldn't have to navigate around all the smaller 5 line functions, at least not unless you're debugging. Each of the submethods should clearly describe what it does, and do that without any unexpected side-effects or implicit state changes. Effectively, what this does is raise the level of abstraction of the code, so that your 50-line function becomes a 10-line function, and you only need to read those 10 lines to understand what's going on. Sometimes when you're debugging, you might need to dip into these subfunctions, but when you do, you should be able to think through them as mostly independent units that just need to do what their name says they will do. This ideally limits the problem of having to load everything that your code is doing into your head all at once in order to reason through it. When you're just reading through the code normally, you should be able to gloss over the details of how the submethods work, just as you probably wouldn't feel compelled to dig into the internals of how a library call like Collections.sort works. The problem is that method decomposition is not always done well, and when there is unexpected behavior or implicit state changes, it can make bad code even harder to navigate. I'd also rather read a well-written 50 line function than a poorly decomposed cluster of 10-line functions. With proper care, though, method decomposition is super helpful.

20years 10y ago
"The problem is that method decomposition is not always done well" Yeah :(
sbov 10y ago
Part of the problem is that the abstraction of "a sorted list" will never change. But the abstraction of "twiddle my foobar" can change on a weekly basis based upon business needs. Because of this the abstractions we write will never be as strong or enduring as those found in the standard library.
- potatoyogurt 10y ago
  Certainly true, but that's not a reason to give up on creating those abstractions, like the post I was replying to was suggesting. It's a reason to be judicious about when it's appropriate to create these abstractions, and in particular about when they should be shared. An abstraction that's used in just one or two places is still really easy to change. A bad abstraction used in a dozen places is a pain the ass to clean up. It's not an easy problem, and it ultimately takes some combination of experience and careful mentoring to learn to identify good and bad abstractions before they're built.
sheepmullet 10y ago
That's the theory. In practice it is difficult to get the right level of abstraction. This is why writing a good library often takes 3x as much effort as writing the equivalent application code.
- tigershark 10y ago
  This only means that you are not putting enough effort when writing your application code compared to the library. So you are basically adding technical debt to your application. Apart from a deadline that will make the project fail if it is missed I don't see any rational reason to add technical debt. And also in that case you must plan some time to remove the technical debt that you just introduced, and better sooner than later. So writing a library is not harder than writing a good application. It is certainly harder than writing quickly a mess of hacks that become an application.

BWStearns 10y ago

Part of that can also be that the helper functions are taking in whole objects (think js mvc style model objects) when they're really doing a date calculation on one field in the objects. It's not bad that the logic is encapsulated, it's that its encapsulated at the wrong layer. I've run across well written 50 line functions in Perl or c# but I would hesitate to call a function in js or other potentially more concise languages well written (discounting lines devoted to object/dict/hash definitions).