Loading ...
Sorry, an error occurred while loading the content.

Re: [extremeperl] Refactorings?

Expand Messages
  • Stephen Nelson
    I ve got a few refactorings on my Perlmonks homenode: http://www.perlmonks.org/index.pl?node_id=2329 There are also references to other refactorings there. I d
    Message 1 of 14 , Jul 30, 2002
    View Source
    • 0 Attachment
      I've got a few refactorings on my Perlmonks homenode:

      http://www.perlmonks.org/index.pl?node_id=2329

      There are also references to other refactorings there. I'd appreciate
      any feedback.

      Rob Nagler wrote:

      > I'm trying to get an idea what people consider useful refactorings.
      >
      > The following refactoring is a very simple one, but I consider it
      > useful to demonstrate how Perl statement modifiers can be used and to
      > introduce the mechanism by which a document refactorings. The format
      > is borrowed from Fowler's Refactoring book (which I highly recommend,
      > btw).
      >
      > I've got a number of other refactorings in my book, but some have said
      > they are too complicated. I'll send out a few refactorings later
      > after I've got some feedback on the format and what your own
      > refactorings.
      >
      > Thanks for the feedback.
      >
      > Rob
      > ----------------------------------------------------------------
      > TITLE: Replace Conditional with Modifier
      >
      > SYNOPSIS
      >
      > You have an if statement with a one-line then clause.
      > Use a Perl statement modifier to keep data flow on the left.
      >
      > unless (defined($value)) {
      > return undef;
      > }
      >
      > becomes
      >
      > return undef unless defined($value);
      >
      >
      > MOTIVATION
      >
      > This refactoring is controversial, if you aren't used to it.
      > I find modifiers are a useful programming technique, when they are
      > available. We use them in natural language prose where it makes
      > sense. The preceding three sentences are completely normal in
      > English even if they sound weird all in a row. The fact is on
      > the left of a qualifying clause. It puts the action up front so
      > you know what might happen, given a set of circumstances.
      >
      > It's common to use return, last, die, etc. in Perl. Early exits limit
      > the nesting depth. This is a good thing. Modifiers take this one
      > step further by eliminating all nesting, if possible. This keeps data
      > flow on the left, which makes it easier to see the side effects, such
      > as early exit.
      >
      > The roots of programming are based in logic, not in cooking recipes.
      > It seems we often forget this. In mathematical theorems, statements
      > are often followed by qualifying clauses such as such that and iff.
      > Most functional languages put the conditional on the left, which is
      > probably a historical artifact of Lisp, a prefix notation language.
      > In Prolog, rules are expressed as a fact followed by a condition.
      > This refactoring emulates the declarative style of Prolog.
      >
      > You shouldn't use this refactoring to slam as many separate statements
      > into a single line as possible. For example, this is the wrong way to
      > use this refactoring:
      >
      > $x = 39, delete($z{$y}) if $is_tuesday; # WRONG USAGE
      >
      > This line defeats the motivation of keeping the data flow on the left.
      > Too much is happening in one line, and the data operations are
      > complete unrelated. This example obfuscates the data flow instead of
      > improving it.
      >
      > You can convert any if statement into a
      > do-if, e.g.
      >
      > do { # WRONG USAGE
      > $x = 39;
      > delete($z{$y});
      > } if $is_tuesday;
      >
      > This doesn't save nesting. There's more code than a simple if
      > statement. We aren't trying to put all conditionals last. That's as
      > unnatural as ending all conditional English statements with modifying
      > clauses.
      >
      > MECHANICS
      >
      > 1. If the conditional part declares a temporary
      > my variable, move the declaration part out.
      >
      > 2. Remove the braces from the statement and switch the conditional
      > order. Do not change the conditional logic.
      >
      > EXAMPLE
      >
      > Here's a method with two one-line if statements:
      >
      > sub from_literal {
      > my(undef, $value) = @_;
      > unless (defined($value)) {
      > return undef;
      > }
      > $value =~ s/^\s+|\s+$//g;
      > unless (defined($value)) {
      > return undef;
      > }
      > return $value;
      > }
      >
      > We transform the two conditionals into modified statements:
      >
      > sub from_literal {
      > my(undef, $value) = @_;
      > return undef unless defined($value);
      > $value =~ s/^\s+|\s+$//g;
      > return undef unless length($value);
      > return $value;
      > }
      >
      >
      >
      > Yahoo! Groups Sponsor
      > ADVERTISEMENT
      > <http://rd.yahoo.com/M=228862.2128520.3581629.1829184/D=egroupweb/S=1705007181:HM/A=1155069/R=0/*http://adfarm.mediaplex.com/ad/ck/990-1736-1039-302>
      >
      >
      >
      > To unsubscribe from this group, send an email to:
      > extremeperl-unsubscribe@yahoogroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
      > <http://docs.yahoo.com/info/terms/> .
      > .




      [Non-text portions of this message have been removed]
    • Adrian Howard
      ... [snip] Okay... here s one. (I don t have my Fowler to hand, so please excuse me if I wander off the standard format :-) ... TITLE: HashBecomesObject
      Message 2 of 14 , Jul 30, 2002
      View Source
      • 0 Attachment
        On Monday, July 29, 2002, at 04:02 pm, Rob Nagler wrote:

        > I'm trying to get an idea what people consider useful refactorings.
        [snip]

        Okay... here's one.

        (I don't have my Fowler to hand, so please excuse me if I wander off
        the "standard" format :-)

        ---

        TITLE: HashBecomesObject

        SYNOPSIS:

        Turn a hash that represents a separate entity into an blessed object
        that reflects it's purpose.

        $Tests->{$class}->{$method}->{num_tests} = 4;
        $Tests->{$class}->{$method}->{type}->{setup} = 1;
        $Tests->{$class}->{$method}->{type}->{teardown} = 1;

        becomes:

        my $info = bless {}, 'Test::MethodInfo';
        $info->{num_tests} = 4;
        $info->{type}->{setup} = 1;
        $info->{type}->{teardown}=1;
        $Tests->{$class}->{$method} = $info;

        MOTIVATION:

        Perl lets you quickly create complex data-structures out of
        hashes-of-hashes, often acting as simple collections.

        These can quickly become hard to comprehend, use and maintain.

        If a part of a hash-of-hashes (or a hash all by it's lonesome) makes
        sense as a separate entity, turn it into an blessed hash.

        This acts as a precursor to things like ExtractClass and allows
        HashAccessBecomesMethodCall for your new object (I'll leave
        HashAccessBecomesMethodCall, and the obvious ObjectBecomesHash as
        exercises for the reader :-)

        ----

        I'm tempted to stick up a perl refactoring wiki (or is there one
        already hiding in a corner somewhere?)... Anybody second the
        suggestion?

        Adrian
        --
        Adrian Howard <adrianh@...>
        phone: 01929 550720 fax: 0870 131 3033 www.quietstars.com
      • Stephen Nelson
        Seconded.... I ve been planning on doing that for way too long. ... [Non-text portions of this message have been removed]
        Message 3 of 14 , Jul 30, 2002
        View Source
        • 0 Attachment
          Seconded.... I've been planning on doing that for way too long.

          Adrian Howard wrote:

          > On Monday, July 29, 2002, at 04:02 pm, Rob Nagler wrote:
          >
          > > I'm trying to get an idea what people consider useful refactorings.
          > [snip]
          >
          > Okay... here's one.
          >
          > (I don't have my Fowler to hand, so please excuse me if I wander off
          > the "standard" format :-)
          >
          > ---
          >
          > TITLE: HashBecomesObject
          >
          > SYNOPSIS:
          >
          > Turn a hash that represents a separate entity into an blessed object
          > that reflects it's purpose.
          >
          > $Tests->{$class}->{$method}->{num_tests} = 4;
          > $Tests->{$class}->{$method}->{type}->{setup} = 1;
          > $Tests->{$class}->{$method}->{type}->{teardown} = 1;
          >
          > becomes:
          >
          > my $info = bless {}, 'Test::MethodInfo';
          > $info->{num_tests} = 4;
          > $info->{type}->{setup} = 1;
          > $info->{type}->{teardown}=1;
          > $Tests->{$class}->{$method} = $info;
          >
          > MOTIVATION:
          >
          > Perl lets you quickly create complex data-structures out of
          > hashes-of-hashes, often acting as simple collections.
          >
          > These can quickly become hard to comprehend, use and maintain.
          >
          > If a part of a hash-of-hashes (or a hash all by it's lonesome) makes
          > sense as a separate entity, turn it into an blessed hash.
          >
          > This acts as a precursor to things like ExtractClass and allows
          > HashAccessBecomesMethodCall for your new object (I'll leave
          > HashAccessBecomesMethodCall, and the obvious ObjectBecomesHash as
          > exercises for the reader :-)
          >
          > ----
          >
          > I'm tempted to stick up a perl refactoring wiki (or is there one
          > already hiding in a corner somewhere?)... Anybody second the
          > suggestion?
          >
          > Adrian
          > --
          > Adrian Howard <adrianh@...>
          > phone: 01929 550720 fax: 0870 131 3033 www.quietstars.com
          >
          >
          > Yahoo! Groups Sponsor
          > ADVERTISEMENT
          > <http://rd.yahoo.com/M=228862.2128520.3581629.1829184/D=egroupweb/S=1705007181:HM/A=1155070/R=0/*http://adfarm.mediaplex.com/ad/ck/990-1736-1039-302>
          >
          >
          >
          > To unsubscribe from this group, send an email to:
          > extremeperl-unsubscribe@yahoogroups.com
          >
          >
          >
          > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
          > <http://docs.yahoo.com/info/terms/> .
          > .




          [Non-text portions of this message have been removed]
        Your message has been successfully submitted and would be delivered to recipients shortly.