Are you looking for more discussion? ;)

I was just thinking about this today. My conclusion is that function length is a good question, but not the whole story.

What's more important is complexity, as one of your perlmonks pointed out. But complexity has an odd relationship with function length: programs should vary greatly in complexity; functions should not.

Take subclassing, for example. I tend to have a rule of thumb that subclassing is great when applied once. Once in a while, I might subclass a subclass. I almost never go more than two levels deep. Why? Because this exceeds a level of complexity with which I am comfortable. I tend to think of subclassing in terms like "base class" -> "subtype" -> "instance". Anything more complex, and I start to lose understanding.

Ever try to fold a piece of paper multiple times? Anecdotes say that for any square piece of paper, it's impossible to fold it more than seven times. This is probably due in part to edge formation rules, but it's also a symptom of the fact that, to end up with a square one inch on each side, you'd have to start with a sheet 256 inches (over 21 feet) on each side for 8 folds!

In programming, we have multiple constructs to handle this problem. Expressions and statements at the lowest levels, then combined expressions like f(g(x)), blocks and loops, functions, classes, modules, packages, applications, etc. Add your particular favorite constructs in where you feel like it.

Back to the subclassing example. Once we move into the class hierarchy construct, there's a limit to the amount of complexity we can maintain in that layer. It's possible to have 72 levels of subclasses, but you end up with a problem: a base class so abstract, not even light can escape. At some point, most programmers decide to "bump up" the complexity to the next construct.

Given all of that, it's nice to have a fairly common function length. Like one of the perlmonkeys, I like about a "page length". The point is that functions are constructs; they are able to support infinite complexity; but when other constructs are available, they probably shouldn't.

Side note: it's common for procedural coders to consider their code, with inline comments, as the whole program. OO'ers I know tend to view a program as code plus design docs. They're more used to thinking in terms of multiple levels of complexity (in my experience).

Post #121,112 by FuManChu 10/13/03 8:06:33 PM Reply	Are you looking for more discussion? ;) I was just thinking about this today. My conclusion is that function length is a good question, but not the whole story. What's more important is complexity, as one of your perlmonks pointed out. But complexity has an odd relationship with function length: programs should vary greatly in complexity; functions should not. Take subclassing, for example. I tend to have a rule of thumb that subclassing is great when applied once. Once in a while, I might subclass a subclass. I almost never go more than two levels deep. Why? Because this exceeds a level of complexity with which I am comfortable. I tend to think of subclassing in terms like "base class" -> "subtype" -> "instance". Anything more complex, and I start to lose understanding. Ever try to fold a piece of paper multiple times? Anecdotes say that for any square piece of paper, it's impossible to fold it more than seven times. This is probably due in part to edge formation rules, but it's also a symptom of the fact that, to end up with a square one inch on each side, you'd have to start with a sheet 256 inches (over 21 feet) on each side for 8 folds! In programming, we have multiple constructs to handle this problem. Expressions and statements at the lowest levels, then combined expressions like f(g(x)), blocks and loops, functions, classes, modules, packages, applications, etc. Add your particular favorite constructs in where you feel like it. Back to the subclassing example. Once we move into the class hierarchy construct, there's a limit to the amount of complexity we can maintain in that layer. It's possible to have 72 levels of subclasses, but you end up with a problem: a base class so abstract, not even light can escape. At some point, most programmers decide to "bump up" the complexity to the next construct. Given all of that, it's nice to have a fairly common function length. Like one of the perlmonkeys, I like about a "page length". The point is that functions are constructs; they are able to support infinite complexity; but when other constructs are available, they probably shouldn't. Side note: it's common for procedural coders to consider their code, with inline comments, as the whole program. OO'ers I know tend to view a program as code plus design docs. They're more used to thinking in terms of multiple levels of complexity (in my experience). "There's a set of rules that anything that was in the world when you were born is normal and natural. Anything invented between when you were 15 and 35 is new and revolutionary and exciting, and you'll probably get a career in it. Anything invented after you're 35 is against the natural order of things." Douglas Adams
Post #121,255 by ben_tilly 10/15/03 1:34:53 AM Reply	The responses that I liked best... were from the AM who was talking about OO as being a way to manage the coupling in your system. I will need to digest that idea for a bit I think. Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #121,312 by JimWeirich 10/15/03 1:09:06 PM Reply	Re: The responses that I liked best... [...] OO as being a way to manage the coupling in your system Bob Martin from Object Mentor has been pushing the "OO is about coupling" message for many years. If you are not familiar with his writings, check out the object mentor site (a link to the design principles area is: [link\|http://www.objectmentor.com/resources/listArticles?key=topic&topic=Design%20Principles\|http://www.objectmen...sign%20Principles]). The Open/close and Liskov substitution principles are good places to start, but the real practical stuff begins in the Dependency Inversion and Interface Segregation principles. -- -- Jim Weirich jweirich@one.net [link\|http://onestepback.org\|http://onestepback.org] --------------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

Welcome to IWETHEY!