6 ms·

What do you think of short methods?

by 6ren 15y ago

wglb 15y ago
A friend of mine who was a smalltalk programmer for 17 years told me that the median length of his methods over his career was four lines. I think that this is admirable and wish my code were more like that.
- 6ren 15y ago
  It seems that having many small methods trades one complexity for another. For methods that are only used once and sequentially, it seems to me that it's easier to follow if they are all inlined (by the programmer). If the methods can be reused elsewhere, it's a different matter. On the other hand, methods are modules, giving syntactic and compiler-supported semantic separation - and you can do things like return early. I can't tell which is better. Some people claim that short is better, but it always comes across as a bit rabidly dogmatic, because... well... it's without evidence. There is so much of that in comp sci: design patterns, functional programming, editor and language choice. Most people giving opinions don't even mention what type of task that advice is relevant for, nor give their experience that supports their choice. (It's easy to argue for a choice - smart people unfortunately can argue convincingly for anything.) I tend to use separate methods only if they are reusable (otherwise it's a waste of time making them reusable). I often think of better ways of doing things, so I don't like to invest too much in what I have now. I'm mostly writing prototype code for new kinds of products, not "production code", not for clients, and no one sees it but me. Much code I've seen that it made of many methods and classes looks horribly over-engineered to me, especially when the problem itself is actually very simple if you approach it in the right way. I'd love to hear gruseom's opinion tho.
  - gruseom 15y ago
    I wrote my thoughts up above, but will respond to this here. I agree, both about the short methods school and about programming dogmas in general. I went through a couple years of working in the OO short method style. Recently an old client called me back to help modify some code I'd done for them in 2004, so I went down for an afternoon to help them out. I was really embarrassed. It was obvious to me that I had strung things together in endless chains of delegation (tiny classes and short methods) not because that was simple but because it, at the time, was my belief about programming. I got that belief from other programmers I admired. The truth is that this is how most of us work all the time. I don't mean short methods; I mean picking a style based on our beliefs -- mostly for emotional reasons -- and then seeing the entire programming world through that filter. To be able to just see the problem is difficult when you're operating from one of these positions. Much (most?) of what we do in software development is add extrinsic complexity, which is bad when the problems themselves are hard to begin with. My experience is that your moment of "the problem itself is actually very simple if you approach it in the right way" does eventually come, if you make getting there a high priority. But it's challenging. Most of the time we don't even know what our assumptions and beliefs are, let alone have the flexibility to adapt them to the problem. It's usually the other way around: we adapt the problem to our beliefs because they determine how we even see the problem in the first place.
  - wglb 15y ago
    I think one key thing to keep in mind is that it is better to chose a style that is more likely to obviously have no errors, rather than one that has no obvious errors. (Wirth?) With longer methods, it becomes more strenuous to say that it obviously has no errors. And in It seems that having many small methods trades one complexity for another. is not a fair representation, as the implied relationship is not linear.
    - 6ren 15y ago
      C.A.R. Hoare (according to http://www.gdargaud.net/Humor/QuotesProgramming.html http://www.gdargaud.net/Humor/QuotesProgramming.html anyway), but I prefer Douglas Adams' formulation, though less clever: their fundamental design flaws are completely hidden by their superficial design flaws Yes, it's true that the compiled-supported semantic modularity of methods helps here: e.g. it can't access other methods' local variables, you can see what goes in and what goes out. But, in a long method, you can manually enforce the same modularity on sequential parts (you can even use local variables scoped by {} to borrow some compiler support). But, yes, point taken. Can you elaborate on the relationship not being linear? I think you mean that the many parts of a long method can interact (if the coder doesn't enforce this manually).
      - wglb 15y ago
        Elaborating: Less complexity in each method leads to less overall complexity. And yes, the worst of long methods is that the internal interaction usually leads to more complexity.
        6ren 15y ago
        I was asking about the "non-linear" part.
        wglb 15y ago
        Perhaps poor choice of phrase. It is my feeling that moving complexity out of methods and possibly having it in the interrelationships between methods results in a net gain in understandability. Perhaps asymmetric would have been a better word?
- gruseom 15y ago
  Hell, this reminds me of another thing I want to say. The word that leaps out here is "smalltalk". The short-method school of OO came from the Smalltalk world. It has since been extrapolated to other languages. I am skeptical of this extrapolation. It's fashionable to say language choice doesn't matter that much, but I think language choice has a powerful effect in conditioning how one thinks about one's program. Different languages give rise to different ideas, and ultimately very different programs. It wouldn't surprise me if the short-method style makes good sense in Smalltalk environments for reasons that don't naively extrapolate to other languages. But that's just a guess. By the way, the reason the above language effect doesn't get discussed is that when we compare languages we're almost always talking about already-existing code (look at how you can write X in Haskell or whatever). This leaves out the most important factor, which is how the language affects the creation of X in the first place.
  - wglb 15y ago
    With respect to specificity of languages, Uncle Bob in "Clean Code" also advocates for extremely short methods in C#, on the same order as what my friend uses. Different languages do give rise to different ideas, but I think that what matters more is how that language thinks about Objects and Classes, as one example. For example, in Smalltalk, methods are messages. In C++ and other contemporaneous langages, nobody talks about messages. They are still procedural chunks, more or less. This fact has a very big influence on how programs are written. Then in CLOS, you have generic methods that don't belong to a class, which is really a third view quite independent of the other two ways of looking at OO. And you get multiple inheritance without any confusion. And taking a look at those suckers, they are generally not very long at all. I have a bunch that are zero lines outside of the defgeneric part. So short methods are also very evident in PGs code. While slightly longer, they are the equivalent of the four-line smalltalk method, and brutally simple. Arc takes this to the next level. Kind of like writing Lisp without vowels.
    - gruseom 15y ago
      I like your phrase "how that language thinks". C# doesn't think like Smalltalk, so it's a mistake to write C# code as if it does. "Uncle" Bob is not a reliable source here. It's been a while since I've read any of PG's code, so the following may be off-base, but I don't think he has any heritage in the OO-short-method school. In his books, at least, he's usually looking for functions that work like language constructs. The hallmark of such constructs is that they can be composed orthogonally. This is not at all true of the long delegation chains favored by classic OO. As for brutal simplicity - a thousand times yes! But what we're discussing is how do you get it. More precisely, how do you get it at the only level that counts: the whole-program level. Otherwise you're just shifting complexity around, and probably thereby increasing it. Edit: Two addenda. (1) I'm surprised to see PG's code come up in the discussion the way it did, because his writings were probably the thing that cured me of OO, or at least convinced me to check myself into detox. (2) I just had the scary thought that someone might read this discussion and think that I'm arguing against short functions in favor of long ones. God no. I'm arguing in favor of short programs against longer programs that have many more function definitions and interactions. Somebody assure me that was clear.
gruseom 15y ago
For fun, I'm going to write my thoughts before reading what you said about it elsewhere in the thread. What do you think of short methods? I'm skeptical of them. I think it's a mistake to try to make functions short for the sake of making them short. It's a mistake because adding a new function also adds complexity (i.e. more code, plus opacity between the calling and called) - not a lot, but greater than zero - so introducing a function is not cost-free and its benefit needs to be greater than its cost. I found that once I started asking functions to justify themselves this way, I began creating fewer functions and the overall complexity of my code went down. Factoring code into functions is one of the best tools we have, of course, but people commonly make the mistake of applying it mechanically. A function should exist when the program itself wants that concept, not because you had a block of code that was too big or some duplication and you wanted to rearrange the pieces. The way to address those symptoms is not by adding more code but by thinking until you see how you were looking at the problem wrongly. Then the new concepts, and finally the new functions, appear by themselves. You only have so many conceptual cards to play and must play them sparingly if you don't want your program to succumb to runaway complexity. A good function is a logical construct that makes sense in the meaning of the program the way a good word makes sense and adds a unique meaning to a language, something you can't quite say as well any other way. When all you're doing is shifting pieces around, you're missing the most important thing about functions, which is this conceptual payload. After you do that for a while, your program stops evolving as an expression of the problem being solved, because you've built it out of primitives that refer only to the internals of the program rather than to concepts drawn from the problem space. Side note. I'm writing at such length here and in the GP because these questions are on my mind all the time. I've been working on a hard problem for over two years now in an utterly immersed way, the kind where you dream about it every night, where time itself begins to blur. Our approach has been to evolve the program many times until it converges on a solution. The only way to do this is if the program doesn't grow as you evolve it. How do you build a system such that you're constantly adding new information and behavior to it, and yet the overall code doesn't grow? We've had to figure this out just to stay alive. One more thing about function length - Steve McConnell cites studies that suggest that short functions aren't easier to understand. IIRC the sweet spot was between 50 and 100 lines, depending of course on the language. I've posted references to this on HN before. One should be careful about believing these studies because the empirical literature on software development is so poor. But it's at least interesting that such experimental evidence as exists runs counter to the "OO short methods" school.

What do you think of short methods?

by 6ren 15y ago

What do you think of short methods?

wglb 15y ago

A friend of mine who was a smalltalk programmer for 17 years told me that the median length of his methods over his career was four lines. I think that this is admirable and wish my code were more like that.

6ren 15y ago
It seems that having many small methods trades one complexity for another. For methods that are only used once and sequentially, it seems to me that it's easier to follow if they are all inlined (by the programmer). If the methods can be reused elsewhere, it's a different matter. On the other hand, methods are modules, giving syntactic and compiler-supported semantic separation - and you can do things like return early. I can't tell which is better. Some people claim that short is better, but it always comes across as a bit rabidly dogmatic, because... well... it's without evidence. There is so much of that in comp sci: design patterns, functional programming, editor and language choice. Most people giving opinions don't even mention what type of task that advice is relevant for, nor give their experience that supports their choice. (It's easy to argue for a choice - smart people unfortunately can argue convincingly for anything.) I tend to use separate methods only if they are reusable (otherwise it's a waste of time making them reusable). I often think of better ways of doing things, so I don't like to invest too much in what I have now. I'm mostly writing prototype code for new kinds of products, not "production code", not for clients, and no one sees it but me. Much code I've seen that it made of many methods and classes looks horribly over-engineered to me, especially when the problem itself is actually very simple if you approach it in the right way. I'd love to hear gruseom's opinion tho.
- gruseom 15y ago
  I wrote my thoughts up above, but will respond to this here. I agree, both about the short methods school and about programming dogmas in general. I went through a couple years of working in the OO short method style. Recently an old client called me back to help modify some code I'd done for them in 2004, so I went down for an afternoon to help them out. I was really embarrassed. It was obvious to me that I had strung things together in endless chains of delegation (tiny classes and short methods) not because that was simple but because it, at the time, was my belief about programming. I got that belief from other programmers I admired. The truth is that this is how most of us work all the time. I don't mean short methods; I mean picking a style based on our beliefs -- mostly for emotional reasons -- and then seeing the entire programming world through that filter. To be able to just see the problem is difficult when you're operating from one of these positions. Much (most?) of what we do in software development is add extrinsic complexity, which is bad when the problems themselves are hard to begin with. My experience is that your moment of "the problem itself is actually very simple if you approach it in the right way" does eventually come, if you make getting there a high priority. But it's challenging. Most of the time we don't even know what our assumptions and beliefs are, let alone have the flexibility to adapt them to the problem. It's usually the other way around: we adapt the problem to our beliefs because they determine how we even see the problem in the first place.
- wglb 15y ago
  I think one key thing to keep in mind is that it is better to chose a style that is more likely to obviously have no errors, rather than one that has no obvious errors. (Wirth?) With longer methods, it becomes more strenuous to say that it obviously has no errors. And in It seems that having many small methods trades one complexity for another. is not a fair representation, as the implied relationship is not linear.
  - 6ren 15y ago
    C.A.R. Hoare (according to http://www.gdargaud.net/Humor/QuotesProgramming.html http://www.gdargaud.net/Humor/QuotesProgramming.html anyway), but I prefer Douglas Adams' formulation, though less clever: their fundamental design flaws are completely hidden by their superficial design flaws Yes, it's true that the compiled-supported semantic modularity of methods helps here: e.g. it can't access other methods' local variables, you can see what goes in and what goes out. But, in a long method, you can manually enforce the same modularity on sequential parts (you can even use local variables scoped by {} to borrow some compiler support). But, yes, point taken. Can you elaborate on the relationship not being linear? I think you mean that the many parts of a long method can interact (if the coder doesn't enforce this manually).
    - wglb 15y ago
      Elaborating: Less complexity in each method leads to less overall complexity. And yes, the worst of long methods is that the internal interaction usually leads to more complexity.
      - 6ren 15y ago
        I was asking about the "non-linear" part.
        wglb 15y ago
        Perhaps poor choice of phrase. It is my feeling that moving complexity out of methods and possibly having it in the interrelationships between methods results in a net gain in understandability. Perhaps asymmetric would have been a better word?
gruseom 15y ago
Hell, this reminds me of another thing I want to say. The word that leaps out here is "smalltalk". The short-method school of OO came from the Smalltalk world. It has since been extrapolated to other languages. I am skeptical of this extrapolation. It's fashionable to say language choice doesn't matter that much, but I think language choice has a powerful effect in conditioning how one thinks about one's program. Different languages give rise to different ideas, and ultimately very different programs. It wouldn't surprise me if the short-method style makes good sense in Smalltalk environments for reasons that don't naively extrapolate to other languages. But that's just a guess. By the way, the reason the above language effect doesn't get discussed is that when we compare languages we're almost always talking about already-existing code (look at how you can write X in Haskell or whatever). This leaves out the most important factor, which is how the language affects the creation of X in the first place.
- wglb 15y ago
  With respect to specificity of languages, Uncle Bob in "Clean Code" also advocates for extremely short methods in C#, on the same order as what my friend uses. Different languages do give rise to different ideas, but I think that what matters more is how that language thinks about Objects and Classes, as one example. For example, in Smalltalk, methods are messages. In C++ and other contemporaneous langages, nobody talks about messages. They are still procedural chunks, more or less. This fact has a very big influence on how programs are written. Then in CLOS, you have generic methods that don't belong to a class, which is really a third view quite independent of the other two ways of looking at OO. And you get multiple inheritance without any confusion. And taking a look at those suckers, they are generally not very long at all. I have a bunch that are zero lines outside of the defgeneric part. So short methods are also very evident in PGs code. While slightly longer, they are the equivalent of the four-line smalltalk method, and brutally simple. Arc takes this to the next level. Kind of like writing Lisp without vowels.
  - gruseom 15y ago
    I like your phrase "how that language thinks". C# doesn't think like Smalltalk, so it's a mistake to write C# code as if it does. "Uncle" Bob is not a reliable source here. It's been a while since I've read any of PG's code, so the following may be off-base, but I don't think he has any heritage in the OO-short-method school. In his books, at least, he's usually looking for functions that work like language constructs. The hallmark of such constructs is that they can be composed orthogonally. This is not at all true of the long delegation chains favored by classic OO. As for brutal simplicity - a thousand times yes! But what we're discussing is how do you get it. More precisely, how do you get it at the only level that counts: the whole-program level. Otherwise you're just shifting complexity around, and probably thereby increasing it. Edit: Two addenda. (1) I'm surprised to see PG's code come up in the discussion the way it did, because his writings were probably the thing that cured me of OO, or at least convinced me to check myself into detox. (2) I just had the scary thought that someone might read this discussion and think that I'm arguing against short functions in favor of long ones. God no. I'm arguing in favor of short programs against longer programs that have many more function definitions and interactions. Somebody assure me that was clear.

gruseom 15y ago

For fun, I'm going to write my thoughts before reading what you said about it elsewhere in the thread. What do you think of short methods? I'm skeptical of them. I think it's a mistake to try to make functions short for the sake of making them short. It's a mistake because adding a new function also adds complexity (i.e. more code, plus opacity between the calling and called) - not a lot, but greater than zero - so introducing a function is not cost-free and its benefit needs to be greater than its cost. I found that once I started asking functions to justify themselves this way, I began creating fewer functions and the overall complexity of my code went down. Factoring code into functions is one of the best tools we have, of course, but people commonly make the mistake of applying it mechanically. A function should exist when the program itself wants that concept, not because you had a block of code that was too big or some duplication and you wanted to rearrange the pieces. The way to address those symptoms is not by adding more code but by thinking until you see how you were looking at the problem wrongly. Then the new concepts, and finally the new functions, appear by themselves. You only have so many conceptual cards to play and must play them sparingly if you don't want your program to succumb to runaway complexity. A good function is a logical construct that makes sense in the meaning of the program the way a good word makes sense and adds a unique meaning to a language, something you can't quite say as well any other way. When all you're doing is shifting pieces around, you're missing the most important thing about functions, which is this conceptual payload. After you do that for a while, your program stops evolving as an expression of the problem being solved, because you've built it out of primitives that refer only to the internals of the program rather than to concepts drawn from the problem space. Side note. I'm writing at such length here and in the GP because these questions are on my mind all the time. I've been working on a hard problem for over two years now in an utterly immersed way, the kind where you dream about it every night, where time itself begins to blur. Our approach has been to evolve the program many times until it converges on a solution. The only way to do this is if the program doesn't grow as you evolve it. How do you build a system such that you're constantly adding new information and behavior to it, and yet the overall code doesn't grow? We've had to figure this out just to stay alive. One more thing about function length - Steve McConnell cites studies that suggest that short functions aren't easier to understand. IIRC the sweet spot was between 50 and 100 lines, depending of course on the language. I've posted references to this on HN before. One should be careful about believing these studies because the empirical literature on software development is so poor. But it's at least interesting that such experimental evidence as exists runs counter to the "OO short methods" school.