5 ms·

> can later be called in the wrong order I'm thankful I'm not the only one with this critique. I see this so often and it makes navigating and/or debugging the

> can later be called in the wrong order I'm thankful I'm not the only one with this critique. I see this so often and it makes navigating and/or debugging the code a nightmare, while I hop around these tiny single use methods. A long function I can read top to bottom is a lot easier to grok!

forgetfulness 4y ago
Examples of that were common in 2000s poor Object Oriented Programming introductory material, do people still advise that kind of design? There were people who abhorred the sight of non-stateful code, there was little opportunity to fiddle with objects in it, not realizing that they just made their and everyone else's job harder with more moving parts, a concept that, despite being very easy to understand and with analogues to physical machines, was lost on many programmers.
- johannes1234321 4y ago
  > do people still advise that kind of design? It is a constant discussion. You can always find examples of long functions with lots of state which is hard to follow and then there are always examples of code where people went too short. And then there are always people taking any of those examples and showing why they were wrong. I myself like going to the extremes for fun/toy/throwaway projects (not only on these but also with rules like "no `if`" or "no raw `for` loop" etc) to try out all the different alternatives and then resetting my default based on cases where it went well and where it went bad. No such rule is always right, but most hmstem from being exposed to too much of one extreme.
- layer8 4y ago
  The correct way to do this, if it really is a significant simplification, is to factor out the minimal relevant code into a private helper class (or struct) that you instantiate anew for each computation. It then functions like a stack frame you can pass around and share between functions/methods, within private boundaries.
BurningFrog 4y ago
I used to call this the "Poltergeist Pattern". Tons of tiny functions, each doing almost nothing, frantically calling each other, and somehow useful functionality results. Each function is very easy to understand, but how they together do useful tasks is near incomprehensible.
- camgunz 4y ago
  I had a gig where a consultant had just been through (before I started), and totally changed the programming culture of the engineering teams. One of the weird things that happened was my new team no longer tolerated methods > 10 lines, which created exactly what you're talking about: a bunch of tiny single-use methods and helpers scattered across other classes/files/modules/libraries that totally obscured control flow. It's amazing to me how even smart people can be taken in by Harold Hill types. Can I get a job going around giving advice for $100k a pop? I promise to do better than that guy haha.
  - tziki 4y ago
    That's funny, I wonder how nobody thought to challenge that.
    - ratww 4y ago
      In a team I was part of, we used the default in a popular Ruby linter, Reek. And it wasn't 10, it was 5. The team treated that as puzzle-solving, and it was part of their culture to tackle those kinds of challenges. There was light hazing of newbies whenever the CI didn't pass because methods were too big. So, that's why at least in this case. There was no technical argument, just inertia. Code quality was atrocious. Things that could be 10 lines were 30 or 40, and extremely stateful.
- btschaegg 4y ago
  On that topic: I came to like John Ousterhout's notion (in [1]) of "deep" methods/classes/etc. He explains it like this: If you have a reusable piece of code, imagine drawing it as a rectangle. The width corresponds to the complexity of the interface, the depth corresponds to the complexity of the implementation. Ousterhout is saying that we really want deep classes, i.e. the complexity of the implementation a construct hides should be considerably larger than the complexity it takes to use it. Which, at least to me, basically says "search for good abstractions". And what you're describing strikes me as a good way not to achieve that. Of course, there's considerable wiggle room in that mental model, and one could still endlessly squabble about how (not) to break up the implementation. [1]: https://www.amazon.com/Philosophy-Software-Design-John-Ousterhout/dp/1732102201 https://www.amazon.com/Philosophy-Software-Design-John-Ouste...

forgetfulness 4y ago

Examples of that were common in 2000s poor Object Oriented Programming introductory material, do people still advise that kind of design? There were people who abhorred the sight of non-stateful code, there was little opportunity to fiddle with objects in it, not realizing that they just made their and everyone else's job harder with more moving parts, a concept that, despite being very easy to understand and with analogues to physical machines, was lost on many programmers.

johannes1234321 4y ago
> do people still advise that kind of design? It is a constant discussion. You can always find examples of long functions with lots of state which is hard to follow and then there are always examples of code where people went too short. And then there are always people taking any of those examples and showing why they were wrong. I myself like going to the extremes for fun/toy/throwaway projects (not only on these but also with rules like "no `if`" or "no raw `for` loop" etc) to try out all the different alternatives and then resetting my default based on cases where it went well and where it went bad. No such rule is always right, but most hmstem from being exposed to too much of one extreme.
layer8 4y ago
The correct way to do this, if it really is a significant simplification, is to factor out the minimal relevant code into a private helper class (or struct) that you instantiate anew for each computation. It then functions like a stack frame you can pass around and share between functions/methods, within private boundaries.

BurningFrog 4y ago

I used to call this the "Poltergeist Pattern". Tons of tiny functions, each doing almost nothing, frantically calling each other, and somehow useful functionality results. Each function is very easy to understand, but how they together do useful tasks is near incomprehensible.

camgunz 4y ago
I had a gig where a consultant had just been through (before I started), and totally changed the programming culture of the engineering teams. One of the weird things that happened was my new team no longer tolerated methods > 10 lines, which created exactly what you're talking about: a bunch of tiny single-use methods and helpers scattered across other classes/files/modules/libraries that totally obscured control flow. It's amazing to me how even smart people can be taken in by Harold Hill types. Can I get a job going around giving advice for $100k a pop? I promise to do better than that guy haha.
- tziki 4y ago
  That's funny, I wonder how nobody thought to challenge that.
  - ratww 4y ago
    In a team I was part of, we used the default in a popular Ruby linter, Reek. And it wasn't 10, it was 5. The team treated that as puzzle-solving, and it was part of their culture to tackle those kinds of challenges. There was light hazing of newbies whenever the CI didn't pass because methods were too big. So, that's why at least in this case. There was no technical argument, just inertia. Code quality was atrocious. Things that could be 10 lines were 30 or 40, and extremely stateful.
btschaegg 4y ago
On that topic: I came to like John Ousterhout's notion (in [1]) of "deep" methods/classes/etc. He explains it like this: If you have a reusable piece of code, imagine drawing it as a rectangle. The width corresponds to the complexity of the interface, the depth corresponds to the complexity of the implementation. Ousterhout is saying that we really want deep classes, i.e. the complexity of the implementation a construct hides should be considerably larger than the complexity it takes to use it. Which, at least to me, basically says "search for good abstractions". And what you're describing strikes me as a good way not to achieve that. Of course, there's considerable wiggle room in that mental model, and one could still endlessly squabble about how (not) to break up the implementation. [1]: https://www.amazon.com/Philosophy-Software-Design-John-Ousterhout/dp/1732102201 https://www.amazon.com/Philosophy-Software-Design-John-Ouste...