There is certainly the case for long methods/subs/procs/funcs if the code is just following one long sequence of actions. A lot of Delphi code that I maintain does that and I think it's not a bad state for that particular type of code, even though the Delphi IDE has auto code hyperlinking, which is great for skipping from one method to another. On the other hand I find that where there is branching it is best to use short methods/subs/procs/funcs that are preferably no more than one screen long, not actually that different from code 'paragraphs'. I general, what most people really want is not strict adherence to coding standards, but to see most of what they need to at a glance and either a short method/sub/proc/func or a code paragraph should be used where applicable.
I think the main thing is the advice above the Perlmonks masthead: think about loose coupling. Looser coupling means less copying and pasting should happen. The less copying and pasting, the less need for parallel maintenance and the less chance for hard to find bugs. The two TDDs should facilitate looser coupling. I learned Top Down Design at school (though it doesn't always come naturally) and I'm now (several years too late) trying to get my head into Test Driven Development. I'm too conservative to be into Xtreme refactoring, especially for maintenance, but I have recently found a bit of refactoring to be useful in my own code.
How can you feel when you're made of steel? I am made of steel. I am the Robot Tourist.
Robot Tourist, by Ten Benson
