Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re: Re: Re: Short routines matter more in OO?

by demerphq (Chancellor)
on Oct 13, 2003 at 21:04 UTC ( #298949=note: print w/ replies, xml ) Need Help??


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

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



Comment on Re: Re: Re: Short routines matter more in OO?
Download Code
Re: Re: Re: Re: Short routines matter more in OO?
by Anonymous Monk on Oct 14, 2003 at 00:24 UTC
    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 :-)
Re: Re: Re: Re: Short routines matter more in OO?
by Juerd (Abbot) on Oct 14, 2003 at 07:09 UTC

    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/ }
    versus
    sub property1 : Property; sub property2 : Property;

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

      I was reviewing some of my code and it looks like my sub lengths (excluding short utility subs that would probably be macros in C or inline in other languages) seem to be around 50-150 lines.


      ---
      demerphq

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


      Why are you assigning to $self->{"property$n"} and then returning $self->{property}?

      Your @_ test also makes little sense to me. If you are trying to write get/set routines, you would want to get on a single routine, set on 2, and think about throwing an error on 3 or more. Your methods as written require an extra argument to say, "set, pretty please".

      I was also going to chide you for having methods called property1, property2 without thinking through what you are going to do if you had more than 2 properties, and then I realized that you were likely talking properties of an object, not a computer representation of physical properties. :-)

      Oh, right. If you are going to have a lot of very similar code, then I think that autogenerating can be good. (Assuming, of course, that the person who will take over the code is capable of figuring out autogenerated code...) For instance:

      foreach my $accessor (@object_properties) { no strict 'refs'; *$accessor = sub { my $self = shift; $self->{$accessor} = shift if @_; $self->{$accessor}; }; }
      (Yeah, yeah. A million CPAN modules implement variations on the above for you.)

        Why are you assigning to $self->{"property$n"} and then returning $self->{property}?

        That is a typo, which I then copied.

        Your @_ test also makes little sense to me. If you are trying to write get/set routines, you would want to get on a single routine, set on 2, and think about throwing an error on 3 or more.

        Yes. This is another typo. Should have been >=, not >. The error on 3 or more makes sense, but I usually forget those.

        Fortunately, I have Attribute::Property, so I can even write working code when I'm as tired as I was when I wrote that node.

        If you are going to have a lot of very similar code, then I think that autogenerating can be good.

        I've put all my favourite object-property-code in Attribute::Property, together with xmath. It was originally made to allow $foo->bar = 14; syntax, but I use it now mostly because it makes creating classes much easier. (And when I'm tired, apparently this means I make less mistakes. See the other node: I made no mistake in the lines that use : Property :-))

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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://298949]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (7)
As of 2014-07-29 21:44 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (228 votes), past polls