... snip ....

Alas, How True. I really looked up a thesaurus once.

no kidding.  does anyone here want to walk in on a method 1200 lines
along and try and debug it?   comments can only go so far.  one vote
for machine generated and used only.

I was guilty of this sort of behavior when I got my first internship.

People do learn, especially if someone gives them a chance by telling
them how to do better.

Most of my deeper understanding of OO, software engineering, and
coding for maintainability happened after I graduated, not before.

Was the pre or post 1.5?

If it was before, then perhaps now it should be 4 or 5

1.5 has made a massive impact on my method size, that 'for each' construct
is superb!

I think 7 is perhaps a little UTT though if I were to pick some magic number
I'd say max of about 10

--
Mike W

JIT-compiled Java will almost certainly beat hand-written x86 these days
(certainly my x86, and I used to be good at it!), but I'd agree with
swapping over to C.

How much surely depends on how much processing is actually occuring.
A large method could be a complex, but be executed quickly - and the
performance overhead of calling methods could make them a bad idea.
The best example I can think of is written in C, but the same reasons apply:
Cafty is a chess-playing engine written in C. The code it uses to evaluate a
board position in its tree is run *very* frequently, and as a result is
heavily optimised and very complex. While it is not all one function, it's
very close - the evaulatePawns() function is about 1100 line long (some of
which is comments, however). (And the code that runs evaluations is about
4000 lines in total)
On the other hand, a modern desktop machine can evaluate (and hash, handle
in a tree etc) over 2 million positions a second.

Alun Harford

(Note: I am not advocating large methods in general - I'm saying that there
are a few obscure situations where they are justified)

Sounds like you got that from the "seven plus or minus two" rule, based
on George Miller's work on the number of discrete pieces of information
that an average person can hold in their short-term memory at any given
point in time.

The problem is that this number doesn't really apply to where you're
using it.  There are several reasons for this:

- It's not the 1950s.  Despite the popularity of George Miller's work
and its very well-documented procedure, more recent studies have cast
great doubt over the truth of his results.

- Lines of code are not discrete pieces of information.  They can be
less discrete (in that one line is often intimately connected with those
around it) or less coherent (i.e., perhaps you should count a line of
code that chains several method calls as two  

- Lines of code aren't held in short-term memory.  The part of the brain
exercised by reading code is analytical.  The code is sitting right in
front of you.  Reading code doesn't mean memorizing the lines.  Pieces
of information that are held in memory (whether short-term or otherwise)
are generally elsewhere; the name of the class, where it fits into the
system, the names and purposes of instance fields, etc.

- Programmers aren't average people.  Software developers work with
large numbers of tidbits of information for a living.  Writing code as
if they are average in this respect is a waste of resources.  I wish I
remembered the source (more because I'd like to reread it than to cite
it... this is just USENET after all), but there's one particularly
interesting book out there in which someone repeated George Miller's
work with software developers, and found that for the really "natrual"
programmers - those for whom writing complex code is easy, the number is
more like 50 to 100, dozens of standard deviations above George Miller's
original number.

My rule of thumb (stated on this group more than once in the past) is as
follows: if there is a strong abstraction, extract a new method.  
Otherwise, don't bother with the length of your methods.  A strong
abstraction can be recognized as follows: (a) there is an obvious SHORT
name for the new method; and (b) when a programmer who hasn't read that
method sees your name, the entire set of inputs and outputs and side-
effects of that method are brought to mind.  That doesn't exclude the
possibility that the programmer would need to know the whole contract,
but nothing in that contract should be truly surprising.

Of course, there are also other reasons to write methods (to provide an
interface to others, to conform to a specified interface, to eliminate
redundancies)... but in terms of shortening methods, it should be done
based on the availability of abstractions.  Otherwise, people just have
to go look up the methods you've extracted to see what they do... and
then it IS about short-term memory because they have to memorize that
section to use it after returning to your code.

   Though coming from C++ and using Java only once in a while for
mobile development, I found the above comment of yours very valuable.
Worth pointing out :)

   Only one question arose in my mind: When having many  /many/  tiny
methods, you need the big picture of the project, or else you might end
up writing duplicate tiny functions. Or you keep spending time trying to
find out, if a function for a small task exists or not .. until you do
have the big picture, which, if the number of tiny methods is just high
enough, might never happen.

regards