4 ms·

Surely one long function is very much harder to test than several shorter ones? So in the context of unit-testing at least, testability is in harmony with Fowle

by Khaki 17y ago

Surely one long function is very much harder to test than several shorter ones? So in the context of unit-testing at least, testability is in harmony with Fowler's definition of simplicity. Seems like a nice goal to me.

astine 17y ago
I'm with Fowler on this one as well. If you divide out parts of the logic of a single complex function, you can take it one level at a time. Furthermore, if you've divided it well, you can more easily reuse logic. Having a single monolithic function is like having a single monolithic program: usually a bad idea. Granted, I don't like spreading related logic over several files, but that is Java's fault.
- skybrian 17y ago
  For Java I agree, more and shorter methods are better. But then I see Haskell programs with zillions of one-line functions and higher math to do trivial things, and then I can understand where he's coming from.
  - Chris_Newton 17y ago
    I'd suggest that the important thing is not how many lines a function has, but whether it represents a single, cohesive idea. Haskell functions aren't shorter because someone decided one day that they should be, they are shorter because Haskell is relatively expressive in some areas. Concepts in suitable areas that would take several lines to represent in another language might take only a line or two in Haskell. On the other hand, there are other areas where Haskell takes pretty much the same amount of lines as an imperative language, and still others where Haskell's model isn't such a good match and it might require more lines.
    - MikeTaylor 17y ago
      "I'd suggest that the important thing is not how many lines a function has, but whether it represents a single, cohesive idea." I think you have it exactly right, and I wish I'd made that point, as clearly as this, in the original article (or indeed in the followup, which I stupidly did before reading the HN comments about the original.) A function/method is like a paragraph in prose writing. Any good style book will tell you that there is no "right length" for paragraphs (although bad teachers might teach rules like "no less than three lines, no more than ten". A paragraph should be exactly long enough to convey one clear point, whether that takes one line, ten, or twenty. The same for functions. By the way, I'd like to say that a LOT of the comments on this thread are really insightful (i.e. the include insights that are new to me, but which immediately make sense once I see them written down). It's pretty humbling to see this community so quickly come to so many valuable conclusions when my poor, bumbling article took so long to get to where it did. Thanks to all who have contributes -- I hope you'll stick around on The Reinvigorated Programmer and contribute to the discussions on there, too.
olliesaunders 17y ago
Yes. And with testability comes flexibility and maintainability. I think the author is focusing too much the simplicity of familiarization and conceptual weight where, very often, the real challenge with imperative code lies in maintenance.
- deleted 17y ago
  [deleted]

by Khaki 17y ago

astine 17y ago

I'm with Fowler on this one as well. If you divide out parts of the logic of a single complex function, you can take it one level at a time. Furthermore, if you've divided it well, you can more easily reuse logic. Having a single monolithic function is like having a single monolithic program: usually a bad idea. Granted, I don't like spreading related logic over several files, but that is Java's fault.

skybrian 17y ago
For Java I agree, more and shorter methods are better. But then I see Haskell programs with zillions of one-line functions and higher math to do trivial things, and then I can understand where he's coming from.
- Chris_Newton 17y ago
  I'd suggest that the important thing is not how many lines a function has, but whether it represents a single, cohesive idea. Haskell functions aren't shorter because someone decided one day that they should be, they are shorter because Haskell is relatively expressive in some areas. Concepts in suitable areas that would take several lines to represent in another language might take only a line or two in Haskell. On the other hand, there are other areas where Haskell takes pretty much the same amount of lines as an imperative language, and still others where Haskell's model isn't such a good match and it might require more lines.
  - MikeTaylor 17y ago
    "I'd suggest that the important thing is not how many lines a function has, but whether it represents a single, cohesive idea." I think you have it exactly right, and I wish I'd made that point, as clearly as this, in the original article (or indeed in the followup, which I stupidly did before reading the HN comments about the original.) A function/method is like a paragraph in prose writing. Any good style book will tell you that there is no "right length" for paragraphs (although bad teachers might teach rules like "no less than three lines, no more than ten". A paragraph should be exactly long enough to convey one clear point, whether that takes one line, ten, or twenty. The same for functions. By the way, I'd like to say that a LOT of the comments on this thread are really insightful (i.e. the include insights that are new to me, but which immediately make sense once I see them written down). It's pretty humbling to see this community so quickly come to so many valuable conclusions when my poor, bumbling article took so long to get to where it did. Thanks to all who have contributes -- I hope you'll stick around on The Reinvigorated Programmer and contribute to the discussions on there, too.

olliesaunders 17y ago

Yes. And with testability comes flexibility and maintainability. I think the author is focusing too much the simplicity of familiarization and conceptual weight where, very often, the real challenge with imperative code lies in maintenance.

deleted 17y ago
[deleted]