[Tutor] refactoring book and function size

[Gonçalo Rodrigues]

> At 00:06 2002-09-18 -0400, Anthony Barker wrote:
> >I have been reading the book "Refactoring: Improving the Design of
> >Existing Code" it makes for a good read - particularly if you have
> >refactored before on a medium sized project.
> >
> >One thing I found odd is how they pull out very small bits of code and
add
> >them to new routines.
> >
> >I am reading "Code Complete", by Steve McConnell in parallel. - he
> >mentions some research that larger subroutines statistically have fewer
> >bugs than very small ones. The research shows that routines of up to 200
> >lines are not bad.
> >
> >Personally I find readability drops if you have subroutines for less than
> >2-3 statements. Larger routines, with purpose, clean names and simple
> >interfaces make understanding a program or module easier.
>
> There is a big span between 2-3 statements and 200 lines...
>
> You should realize that these people come from different
> backgrounds. McConnell and Code Complete refers mainly to
> C, and I think his research refers to typical procedural
> languages as well.
>
> The XP people have their roots in Smalltalk to a large
> degree (although I'm not sure about Martin Fowler). Both
> Smalltalk syntax and Object-Oriented programming in general
> leads to different optima.
>
> Some friends of mine listened to Fowler talking about this
> in Bergen two years ago, and the thing they mentioned, and
> that he himself even seemed a little puzzled over, was that
> he typically made very small methods in Java these days.
>
> On one hand, it makes each method trivial, but on the other
> hand, it might lead to a situation where you are a bit lost
> with all these methods. In Python there is also the time
> involved in function call overhead to consider.
>
> I suppose it might be a bit like with mathematical proofs,
> that you can disect a problem until each piece is trivial,
> solve each trivial piece, assemble the pieces, and the
> problem is solved without you really understanding the
> whole code. You're still confident in the result as you
> are sure that each piece is correct in itself, and correctly
> used. I'm sure detailed unit testing plays a big part here
> as well.
>
> If you are capable of simplifying the problems very much,
> you will probably end up with shorter routines, and a
> smaller program in all. You will also get fewer bugs.
>
> If you try to split large coherent functions in an
> artificial way without reducing complexity, just to get
> down line-count, I'm guessing things will just get worse.
>

Since my experience is in mathematics let me add here the quip of a
mathematician:

"Make the definitions complex and the proofs trivial"

The parallel of this in programming would be something I have read
somewhere, sometime long ago:

"Make the data complex and the code trivial"

Shift as much complexity to the data as possible seems to me a very good
thumb rule. But of course, I may be way out my depth here since my largest
Python program is (and although I knew a few more languages I have never
done anything worth its salt with them), with all modules counted together,
a little more than a measly 2 kLocs.

Best regards,
Gonçalo Rodrigues