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

Re: [extremeperl] Refactorings?

Expand Messages
  • Rob Nagler
    ... Will do. ... Well, you learn something new everyday. :) Thanks! Rob
    Message 1 of 14 , Jul 30, 2002
    • 0 Attachment
      chromatic writes:
      > That's fine. It's important to demonstrate that you don't always go in one
      > direction.

      Will do.

      > The bare return operator respects the calling context:

      Well, you learn something new everyday. :) Thanks!

      Rob
    • 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 2 of 14 , Jul 30, 2002
      • 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 3 of 14 , Jul 30, 2002
        • 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 4 of 14 , Jul 30, 2002
          • 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.