When writing OO code, short methods matter.

Short code matters always. If you can divide your 250 line snippet into five logical chunks, do so. If not, try to redesign.

Coding habits (eg long routines) which are fine in procedural code, can get you into trouble in OO.

They're not fine and OO is no different from procedural here. Long routines get you into trouble regardless of how the routines are used.

That reading good OO code is line for line harder than good procedural code. (OTOH the OO code can get the job done in less code - if you use it right.)

This is a hard one. I don't really know. I do know that code that uses documented OO is easier to read than code that uses other documented functions. When you have to read line for line (ie: no documentation to help you out), then you're probably right.

OO code is much easier to document, though.

Layering abstractions on top of each other has a significant cost. Don't do it unless there is a corresponding benefit that you can point to for justification.

If the abstraction lets you code faster, do it. If it doesn't, it's not worth a single line of code.

Should the abstraction have too much overhead, you can always choose to make the code uglier to optimize it. This is better than starting with something ugly that can always be made beautiful later, because that never happens once code works.

So what are other people's thoughts/experiences on long functions?

Use short functions, if only to be able to profile (Devel::DProf and friends) and optimize.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }