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


in reply to Short routines matter more in OO?

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' }

Replies are listed 'Best First'.
Re: Re: Short routines matter more in OO?
by Anonymous Monk on Oct 13, 2003 at 15:47 UTC
    Shorter is always better how?

    Less error prone? Five studies cited by McConnel found that routine size was either inversely correlated with error frequency, or not correlated at all [1,2,3,4,5]

    Easier to understood? A study of upper level comp. sci. students found that comprehension of a super-modularized program into routines about 10 lines long was no better than their comprehension of a program with no routines (but when moderate length routines were used, comprehension scores rose 65%). [6]

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

    So, on the one hand we have several empirical studies which find that shorter routines do not require less changes, are not easier to understand, and are not less error prone. All of that relates to software cost in the real world. On the other hand, we have your unsupported opinion. 

    [1] Basili & Perricone (1984) "Software Errors and Complexity: An Empi
+rical
    Investigation."  Communications of the ACM 27, no. 1 (Jan) 42-52.

[2] Shen et al (1985) "Identifying Error-Prone Software --- An Emprici
+al
    Study"  IEEE Transactions on Software Engineering SE-11 (Apr) 317-
+324

[3] Card, Church, & Agresti (1986) "An Empirical Study of Software Des
+ign
    Practices"  IEEE Transactions on Software Engineering SE-12 no 2 (
+Feb)
    264-271

[4] Card & Glass (1990) "Measuring Software Design Quality". Englewood
    CLiffs, N.J.: Prentice Hall

[5] Shelby & Basili (1991) "Analyzing Error-Prone System STructure"  I
+EE
    Transactions on Software Engineering SE-17 no 2 (Feb) 141-152

[6] Conte, Dunsmore, Shen (1986) "Software Engineering Metrics and Mod
+els"
    Menlo Park, Calif: Benjamin/Cummings

[7] Lind & Vairavan (1989) "An Experimental Investigation of Software
    Metrics and Their Relationship to Software Development Effort" IEE
+E
    Transactions on Software Engineering SE-15 no 5 (May) 649-653

    [download]
[reply]
[d/l]
[select]

      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' }

[reply]
        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]
        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]

      Im very glad you spoke up in this column. I don't agree that short subroutines are necessarily more understandable and easier to manage. In fact on the contrary. I've found that short subroutines and methods make understanding the code flow of a program much more difficult. (As yourself and others such as Corion have pointed out.) Your comments here have articulated what I've thought (or felt) when I've seen this argument before. I hate dealing with code where methods only do one or two lines of action and there are many many such methods and subs. By the time I trace through a horrible maze of tiny subs each almost identical to the next my head hurts, I can't get a mental model of the program flow (and I typically want to fly to Australia to strangle the author responsible :-)

      As you said elsewhere, subroutines and methods should be a small and as simple as they can be and get the job done. They shouldn't do multiple things and be huge monstrosities but at the same time they shouldn't be sliced up into bits that are only going to be called from one place.

      For me a sub/method should do a single conceptual task. If that means it ends up quite long (over 50 lines or so) then so be it. I certainly don't spend a lot of time worrying how long my subs are.

      Once again thanks. Tis a pitty you are anonymous or I would follow the nodes you write on a regular basis.

      One last thought though. I think this particular subject has different levels. Experienced programmers can probably argue against tillys advice. We have the knowledge to decide when to sacrfifice a rule of thumb like "keep your subroutine short" on the altar of pragmatism. But for a beginner I think the advice "keep your subroutines short and your methods shorter" is probably sound. Until they have developed a more sophisticated basis by which to decide the rule is probably a sound design/craft guideline. The more you know a subject the easier it is to decide "when to break the rules".

      So thanks to tilly for yet another thought provoking thread, and thanks to yourself for a bit of evidence of the contrary view.


      ---
      demerphq

        First they ignore you, then they laugh at you, then they fight you, then you win.
        -- Gandhi

[reply]
[d/l]
        So thanks to tilly for yet another thought provoking thread, and thanks to yourself for a bit of evidence of the contrary view.
        I don't think mine and tilly's views are actually different (just different angles into this interesting topic). He mentioned an OO colleague of his having problems with McConnell's information regarding longer routine sizes, and he noted he found the OO does tend to have reduced routine (method) sizes (perhaps explaining the OO programmers bias). I agree OO tends to have more shorter routines than equivelant procedural code, and I even waxed (hypo)theoretic on one possible reason this might be so (OO allows organized coupling, freeing the programmer from managing it). Not that OO code can't be found (all too easily) that suffers from overly monolithic routines or overly fragmented routines (there is no spoon, I mean, panacea).
        Tis a pitty you are anonymous or I would follow the nodes you write on a regular basis
        You still can. You just won't know if its one of my better nodes or just some drivel until after you look at it :-)
[reply]

        I hate dealing with code where methods only do one or two lines of action and there are many many such methods and subs.

        So do I, so do I. I like short methods, not tiny ones :) I think screen page (24 lines) size is a good size for subs (methods or non-methods) and anything much larger should be taken apart.

        Subs with only one or two meaningful lines are not what I was talking about when I meant short subs. They're a little too short :)

        I do prefer one-line subs to five-line subs when it comes to often repeated code. 

        sub property1 {
    my ($self, $value) = @_;
    @_ >= 2 and $self->{property1} = $value;  # update: s/>/>=/
    $self->{property1};                       # update: s/property/pro
+perty1/
}
sub property2 {
    my ($self, $value) = @_;
    @_ >= 2 and $self->{property2} = $value;  # update: s/>/>=/
    $self->{property2};                       # update: s/property/pro
+perty2/
}

        [download]
        versus 
        sub property1 : Property;
sub property2 : Property;

        [download]

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

[reply]
[d/l]
[select]

In Section Meditations