http://www.perlmonks.org?node_id=298873


in reply to Re: Re: Short routines matter more in OO?
in thread Short routines matter more in OO?

Less error prone? Five studies cited by McConnel found that routine size was either inversely correlated with error frequency, or not correlated at all

The studies could be right.

Less changes required? Another study finds that code needs to be changed least when routines average 100 - 150 lines.

The study could be right.

On the other hand, we have your unsupported opinion.

Yeah. Unsupported. Maybe even wrong.

But I have found small things to be easier to maintain. More flexible. Easier to change, even though more lines change. Easier to re-use. Small subs are usually easier to read and understand.

Easier to document. This is worth a lot.

Whether or not short subs work for you depends on more than Perl alone. Short subs are better than long subs, much like how short sentences are better than long sentences. The long ones may seem more brilliant and more intelligent, but the shorter ones are clearer and much easier to read.

Guess why books for children use short sentences. Guess why most programming introductions start with printing Hello, world.

Of course, programs/modules with short subroutines are harder to create (since it requires more design) and slower.

I do not know of any study that supports my opinion.
I do not know of any study. I don't care much about studies either, since few are done using the right context and variables.

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

  • Comment on Re: Re: Re: Short routines matter more in OO?

Replies are listed 'Best First'.
Re: Re: Re: Re: Short routines matter more in OO?
by tilly (Archbishop) on Oct 14, 2003 at 03:55 UTC
    I agree that few studies are done using the right context and variables. However it is just as rare that my past experience applies directly to whatever variation life throws me next. Furthermore I am well aware of how easy it is to fool myself.

    Therefore I like to seek an understanding that encompasses as broad a range of experience as possible. That means my experience, the experiences of friends, and studies.

    I don't take the studies' claims as gospel, but if I disagree with what they concluced, I strongly prefer at least having an understanding of why they would have seen what they saw.

[reply]
Re: Re: Re: Re: Short routines matter more in OO?
by Anonymous Monk on Oct 13, 2003 at 18:25 UTC
    Guess why books for children use short sentences.
    Because they are geared toward people who are still learning the requisite language skills.
    Guess why most programming introductions start with printing Hello, world.
    Because they are geared toward people who are still learning the requisite programming skills. And Mathematical introductions don't begin with integrals and derivatives either, but that misses the point as entirely as your two examples.

    One of the tasks of a programmer is to manage complexity. The size of a routine is a trait that is causally unrelated to complexity except in trivial cases. It is true that relatively shorter routines are often a by-product of good complexity management, but not by virtue of shortness itself. The aim should never be about making something smaller, it should be about making it simpler (and simpler for a routine can be with respect to several variables, both locally and globally). 

        $simpler != $shorter;

    [download]
    In fact, as some studies have shown, simpler (in terms of errors, changes required, and even comprehensibility) is not even correlated with smaller size (within upper bounds ranging from 100 to 500 line routines). And with that in mind, I'll paraphrase Einstein: routines should be made as simple as possible, but no simpler!. People who equate smaller with simpler often overshoot the target.
    I do not know of any study. I don't care much about studies either, since few are done using the right context and variables.
    Well, the head-in-the-sand tactic is a common defense of personal opinion.
[reply]
[d/l]

      One of the tasks of a programmer is to manage complexity.

      I like to manage complexity by breaking down the complexity into classes and methods, and keep those methods small AND simple. I know that short doesn't have to mean simple. See Attribute::Property. I also know that simple doesn't have to mean short. But more often than not, they have everything to do with eachother.

      Well, the head-in-the-sand tactic is a common defense of personal opinion.

      Personal study has shown that the sand is nice and warm.

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

[reply]

In Section Meditations