Ron Jeffries wrote:
> 
> I noticed in some code that Chet and I were writing that, as Smalltalkers, we tend to write really
> tiny methods. Here's a patch of code to show what I mean. Pay no attention to what it does, just
> look at how it looks.
> 
>   def filesUnderManagement
>     names = (Dir.entries(@directoryName).select { | each | ! (/.bak/ =~ each) }).sort
>     names.reject { |each| FileTest.directory?(sourceName(each)) }
>   end
> 
>   def archiveFiles
>     Dir.entries(@directoryName + '/archive').reject { | each | /^\./ =~ each }.sort.reverse
>   end
> 
---   8<  snip         snip            snip

I personally can't handle/parse such a number of chained method calls
mentally.
A small number of line per method is a Good Thing -- but if the price is
chaining
more than a few (approx. two or three) methods (to me) it's no better than a
long
method (in terms of LOC).

>   def pattern
>     /(.*)\.(.*)/
>   end
> 
> In this whole program, a code manager we're working on, the longest method is this:
> 
>   def findFirstOccurences(names)
>     current = ''
>     firstOccurrences = []
>     names.each do | each |
>       short = shortName(each)
>       if (short != current)
>         current = short
>         firstOccurrences << each
>       end
>     end
>     firstOccurrences
>   end
> 
> That's 12 lines long and to me it is way too long.
> 
---   8<  snip         snip            snip

The rule one of my supervisors gave me is: 'All method definitions
shall fit into the editor window.' 
That was back in the years of 24 line monitors, any I think this
rule is still OK - in terms of lines.


> And so on.
> 
> Now most of us who read larger methods are used to doing the reverse. We look at a big blob of code
> and figure out little chunks of it. Then maybe we comment the code or make a note or just leave the
> figuring out to the next person.

It's a matter of balance (as is almost everything). You'll always need to
trade method length against number of methods, I guess...
I wonder about some, er, pracmatic advice from Dave and/or Andy. What do you
think?

> 
> Tiny methods -- when you get used to them -- are IME /much/ easier to write and to work with.
> 
> Editor-based languages like Ruby, Java, C++, encourage longer methods because we have to search with
> our eyes to figure things out.
> 
> What does this mean? I don't know. I think it might mean that a browser for Ruby or Java or C++
> would be really good. Visual Age for Java is really wonderful in the hands of people who learn to
> work in the browser mode.

That might mean that we really like so see a class/refactoring browser for
Ruby, does it?


Stephan