--- In parlezuml@yahoogroups.com, "jasongorman_uk" <jason@...> wrote:
>
> > Maybe lines of code per method is the wrong metric?
> >
> > What about the rule of thumb of each method does one thing and one
> > thing only? I'm finding it hard to think of a rule for to really
> > define what "one thing" is, but it's going to make writing unit tests
> > more difficult and complex if you have to test each of your methods
> > for multiple behaviours and side effects.
> >
> > Normally I find that if a method is too long, it's doing too much and
> > should be split into a number of more simple methods.
> >
>
> So if a 5,000 line method only did "one thing", it would be okay?


Nope it would be pretty horrible wouldn't it, and in anything I've
ever written there would have been plenty of places in that 5000 lines
for logical divisions of the code into smaller chunks.

So I don't see the point in having an arbitrary number of lines that
makes a method "too long" when chances are you're going to one day
violate your rule because there's some method that just takes more
than say 20 lines.

So why make an arbitrary rule about a side effect (the number of lines
of code) when you really want a rule based on the metric you're
actually trying to optimise - code simplicity?

What gets measured gets optimised
(http://c2.com/cgi/wiki?WhateverGetsMeasuredGetsOptimized) so if you
measure lines of code, people will optimise their method lengths.
I've seen it before where methods are treated just as "macros" where
code that could be organised much better is distributed ad-hoc amongst
a bunch of methods that you just have to call in the correct order.

But if you measure what you really want to optimise - simplicity
(admittedly you would have to do this manually I think) by imposing
the rule of "one piece of functionality per method" then you're a lot
more likely to get your desired result - simple, atomic methods.

I think ;)