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

Re: [extremeperl] I almost had a heart attack: you call that refactoring???

Expand Messages
  • Rob Kinyon
    . . . THE FIRST TIME IT IS USED ELSEWHERE, YOU MAY COPY IT. . . . . . . I don t think it requires 2 uses of something to copy it. The second time you need
    Message 1 of 17 , Mar 31 11:48 AM
      . . . THE FIRST TIME IT IS USED ELSEWHERE, YOU MAY COPY IT. . . .

      . . . I don't think it requires 2 uses of something to copy it. The
      second time you need something, you refer to the initial use.

      I would argue that you don't know what you're refactoring -to- until
      you've seen the code pulled in three different directions. While
      copying may have a bad connotation to it, I would argue that it's ok
      in an XP project, where the code is in a state of constant
      refactoring.

      Rob
    • Jim Keenan
      ... call ... to ... I agree. As MJD says, Repeated code is a mistake! My own personal rule of thumb: If you use the same code twice, put it in a
      Message 2 of 17 , Apr 1, 2005
        --- In extremeperl@yahoogroups.com, Terrence Brannon <bauhaus@m...>
        wrote:
        >
        > <quote url=http://www.extremeperl.org/bk/refactoring>
        > if a routine is used only in one place, you keep it private within a
        > module. THE FIRST TIME IT IS USED ELSEWHERE, YOU MAY COPY IT. If you
        > find another use for it, you refactor all three uses so that they
        call
        > a single copy of the routine. In XP, we call this the Rule of Three,
        > [1] and basically it says you only know some code is reusable if you
        > copy it two times. Refactoring is the process by which you make the
        > code reusable.
        >
        > </quote>
        >
        > I don't think it requires 2 uses of
        > something to copy it. The second time you need something, you refer
        to
        > the initial use.
        >

        I agree. As MJD says, "Repeated code is a mistake!" My own personal
        rule of thumb: If you use the same code twice, put it in a
        subroutine. If you use the same subroutine in two different scripts,
        put it in a module.

        jimk
      • Rob Kinyon
        That kind of thinking is a shallow solution to the problem of a repeated section of work. What if the repeated code isn t the correct formulation of the
        Message 3 of 17 , Apr 1, 2005
          That kind of thinking is a shallow solution to the problem of a
          repeated section of work. What if the repeated code isn't the correct
          formulation of the abstract solution? I don't know what kind of
          parameters it will need or what kind of API it will need the first or
          second times I use a piece of code. By the -third- time, I have a much
          clearer concept and I can now refactor with confidence.

          Don't have the kneejerk reaction of "Must never repeat code!" Often,
          it is useful to repeat code initially so that refactoring is more
          productive.

          On Apr 1, 2005 1:18 PM, Jim Keenan <jkeen@...> wrote:
          >
          > --- In extremeperl@yahoogroups.com, Terrence Brannon <bauhaus@m...>
          > wrote:
          > >
          > > <quote url=http://www.extremeperl.org/bk/refactoring>
          > > if a routine is used only in one place, you keep it private within a
          > > module. THE FIRST TIME IT IS USED ELSEWHERE, YOU MAY COPY IT. If you
          > > find another use for it, you refactor all three uses so that they
          > call
          > > a single copy of the routine. In XP, we call this the Rule of Three,
          > > [1] and basically it says you only know some code is reusable if you
          > > copy it two times. Refactoring is the process by which you make the
          > > code reusable.
          > >
          > > </quote>
          > >
          > > I don't think it requires 2 uses of
          > > something to copy it. The second time you need something, you refer
          > to
          > > the initial use.
          > >
          >
          > I agree. As MJD says, "Repeated code is a mistake!" My own personal
          > rule of thumb: If you use the same code twice, put it in a
          > subroutine. If you use the same subroutine in two different scripts,
          > put it in a module.
          >
          > jimk
          >
          >
          >
          >
          >
          > ________________________________
          > Yahoo! Groups Links
          >
          >
          > To visit your group on the web, go to:
          > http://groups.yahoo.com/group/extremeperl/
          >
          > 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.
        • Terrence Brannon
          ... The repeated code can be in a sub like Jim said. The third time, you simply rework the *sub* so it works with all 3 uses. If you lollygag around and copy
          Message 4 of 17 , Apr 2, 2005
            Rob Kinyon <rob.kinyon@...> writes:

            > That kind of thinking is a shallow solution to the problem of a
            > repeated section of work. What if the repeated code isn't the correct
            > formulation of the abstract solution?

            The repeated code can be in a sub like Jim said. The third time, you
            simply rework the *sub* so it works with all 3 uses. If you lollygag
            around and copy it, you might forget about it. Or someone else might
            come along and not know about it.

            In fact, I will say for large systems, the goal is to move to modules
            or "Business Objects" immediately. Almost nothing should be done in
            the "action" part of your code but calling Business Actions from
            Business Objects... ever.

            > I don't know what kind of parameters it will need or what kind of API
            > it will need the first or second times I use a piece of code. By the
            > -third- time, I have a much clearer concept and I can now refactor
            > with confidence.

            No, I don't agree and stated why above.

            > >
            > Don't have the kneejerk reaction of "Must never repeat code!"

            I work at a place where we have the exact same business calculations
            in easily 5 places in the code and probably 10. This happens because
            no one had a set of Business Objects to add functionality to. They
            simply went in and k0ded a solution to their problem. And someone else
            did. And someone else quit. And someone new came along and did it
            again. And someone else did it for the other product. And someone else
            did it inside of HTML::Mason.... and when I ask to clean it up, I get
            treated like that unwanted Bible salesman who interrupts your day on
            Saturday.

            So yes, I have become very aggressive about this issue because it is
            easy to lose sight of repeated functionality in big systems where you
            are under time pressure.

            > Often, it is useful to repeat code initially so that refactoring is
            > more productive.

            Well, let's see. Jim + Terrence = 2 against.
            Rob N. + Rob K. = 2 for.

            We are in a deadlock.

            >
            > On Apr 1, 2005 1:18 PM, Jim Keenan <jkeen@...> wrote:
            >>
            >> --- In extremeperl@yahoogroups.com, Terrence Brannon <bauhaus@m...>
            >> wrote:
            >> >
            >> > <quote url=http://www.extremeperl.org/bk/refactoring>
            >> > if a routine is used only in one place, you keep it private within a
            >> > module. THE FIRST TIME IT IS USED ELSEWHERE, YOU MAY COPY IT. If you
            >> > find another use for it, you refactor all three uses so that they
            >> call
            >> > a single copy of the routine. In XP, we call this the Rule of Three,
            >> > [1] and basically it says you only know some code is reusable if you
            >> > copy it two times. Refactoring is the process by which you make the
            >> > code reusable.
            >> >
            >> > </quote>
            >> >
            >> > I don't think it requires 2 uses of
            >> > something to copy it. The second time you need something, you refer
            >> to
            >> > the initial use.
            >> >
            >>
            >> I agree. As MJD says, "Repeated code is a mistake!" My own personal
            >> rule of thumb: If you use the same code twice, put it in a
            >> subroutine. If you use the same subroutine in two different scripts,
            >> put it in a module.
            >>
            >> jimk
            >>
            >>
            >>
            >>
            >>
            >> ________________________________
            >> Yahoo! Groups Links
            >>
            >>
            >> To visit your group on the web, go to:
            >> http://groups.yahoo.com/group/extremeperl/
            >>
            >> 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.
            >
            >
            >
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
            >
            >

            --
            Carter's Compass: I know I'm on the right track when,
            by deleting something, I'm adding functionality.
          • Chris Winters
            ... Sounds like a call to delurk. I agree with Rob and Rob but more for the reason that having an immutable rule like the second time you encounter
            Message 5 of 17 , Apr 2, 2005
              On Apr 2, 2005, at 7:43 AM, Terrence Brannon wrote:
              > Well, let's see. Jim + Terrence = 2 against.
              > Rob N. + Rob K. = 2 for.
              >
              > We are in a deadlock.

              Sounds like a call to delurk. I agree with Rob and Rob but more for the
              reason that having an immutable rule like "the second time you
              encounter functionality you MUST put it in one place" doesn't work as
              well as experience telling you when it is and isn't appropriate to do
              so, particularly when moving code results in less readable code or
              forced argument lists just to make it common.

              Chris

              --
              Chris Winters
              Creating enterprise-capable snack systems since 1988
            • Johan Lindstr�m
              ... The whole reason we have rules is so you _think_ before you break them. -Terry Pratchett Personally, I find that it s sometimes useful to defer refactoring
              Message 6 of 17 , Apr 2, 2005
                At 15:08 2005-04-02, Chris Winters wrote:
                >Sounds like a call to delurk. I agree with Rob and Rob but more for the
                >reason that having an immutable rule like "the second time you
                >encounter functionality you MUST put it in one place" doesn't work as
                >well as experience telling you when it is and isn't appropriate to do
                >so, particularly when moving code results in less readable code or
                >forced argument lists just to make it common.

                The whole reason we have rules is so you _think_ before you break them.
                -Terry Pratchett

                Personally, I find that it's sometimes useful to defer refactoring until I
                have copied-and-modified the code twice. That way I have a better overall
                view of all the requirements of all thre different methods. But this is
                nearly always within the same one- or two hour period when I feel there
                will be more copying going on further down the line.

                I rarely leave things for the next day.


                /J
              • Terrence Brannon
                ... Against: 2 (Jim, Terrence) For: 4 (Rob, Rob, Chris, Johan) ... -- Carter s Compass: I know I m on the right track when, by deleting something, I m adding
                Message 7 of 17 , Apr 2, 2005
                  Johan Lindström <johanl@...> writes:

                  > Personally, I find that it's sometimes useful to defer refactoring until I
                  > have copied-and-modified the code twice.

                  Against: 2 (Jim, Terrence)
                  For: 4 (Rob, Rob, Chris, Johan)

                  :: sigh ::

                  :)

                  --
                  Carter's Compass: I know I'm on the right track when,
                  by deleting something, I'm adding functionality.
                • Tom Vilot
                  ... five, actually. Count me in the for list. By way of introduction, I m an artist and software geek. I have worked with/for Rob on a number of occasions in
                  Message 8 of 17 , Apr 2, 2005
                    > Against: 2 (Jim, Terrence)
                    > For: 4 (Rob, Rob, Chris, Johan)

                    five, actually. Count me in the 'for' list.

                    By way of introduction, I'm an artist and software geek. I have worked
                    with/for Rob on a number of occasions in the past. And I still use bOP
                    for my own projects, even though sometimes I do find myself going "uh
                    .... wtf?"

                    :c)

                    Mostly that's just the proces of shifting from my 'old' imperative
                    programming style into understanding the bOP style.

                    As for this particular topic ... I *know* the second I copy and paste
                    a section of code somewhere that I'm doing 'the wrong thing.' And I'm
                    okay with that. Because I'm in the process of answering one question
                    (will x work) before I answer the question 'what do these to blocks of
                    code really have in common and shouldn't they be abstracted out to be
                    a more general solution?'

                    I answer that second question only after I understand the problem and
                    have realized the necessity for making that code more general.

                    Heck, look at the HOP book. This is almost exactly what he does in his
                    examples. "X works, and so now we can do Y. Y works, so let's
                    generalize the solution and make it more flexible."
                  • Curtis Poe
                    ... May as well make it six. I used to think the never duplicate rule was good and sometimes the second time I do something I refactor on the spot, but I ve
                    Message 9 of 17 , Apr 2, 2005
                      On Apr 2, 2005, at 9:34 AM, Tom Vilot wrote:

                      > > Against: 2 (Jim, Terrence)
                      > > For: 4 (Rob, Rob, Chris, Johan)
                      >
                      > five, actually. Count me in the 'for' list.

                      May as well make it six. I used to think the "never duplicate" rule
                      was good and sometimes the second time I do something I refactor on the
                      spot, but I've been bitten too many times by a quick refactoring only
                      to realize I didn't have a full grasp of what needed to be refactored.
                      3 or more times is a good rule of thumb.

                      There's also a rather subtle problem that exists when you have code
                      that is identical but represents different rules that may diverge in
                      the future. My caffeine-deprived brain can't think of an example right
                      now,

                      And a little point that I like to toss out that (if I may be less than
                      humble) more people should pay attention to: when someone uses
                      all-encompassing terms like "never" and "always", look for a logical
                      flaw. There's often one lurking somewhere nearby. Those terms smack
                      of dogmatism and dogmatism means someone's stopped thinking about
                      something (though it doesn't necessarily mean they're wrong.)

                      Cheers,
                      Ovid

                      [Non-text portions of this message have been removed]
                    • Tom Vilot
                      ... Oh, I don t know ... NEVER use Windows isn t dogmatic. It s obvious.
                      Message 10 of 17 , Apr 2, 2005
                        > And a little point that I like to toss out that (if I may be less than
                        > humble) more people should pay attention to: when someone uses
                        > all-encompassing terms like "never" and "always", look for a logical
                        > flaw. There's often one lurking somewhere nearby. Those terms smack
                        > of dogmatism and dogmatism means someone's stopped thinking about
                        > something (though it doesn't necessarily mean they're wrong.)


                        <begin heavy sarcasm>
                        Oh, I don't know ...

                        NEVER use Windows isn't dogmatic. It's obvious.

                        </end heavy sarcasm.

                        But seriously, your point is well taken.
                      • Johan Lindstr�m
                        ... If it s identical now but represents different things, doesn t that smell of badly chosen names for those things? If so, perhaps some things should be
                        Message 11 of 17 , Apr 2, 2005
                          At 19:46 2005-04-02, Curtis Poe wrote:
                          >There's also a rather subtle problem that exists when you have code
                          >that is identical but represents different rules that may diverge in
                          >the future. My caffeine-deprived brain can't think of an example right
                          >now,

                          If it's identical now but represents different things, doesn't that smell
                          of badly chosen names for those things? If so, perhaps some things should
                          be renamed to better reflect "what they are"? That would expose the
                          duplication and you could refactor it properly.


                          /J
                        • Jim Keenan
                          ... the ... as ... But if you double-check my original posting to this thread, you will see that I did not call for an immutable rule. I described instead
                          Message 12 of 17 , Apr 2, 2005
                            --- In extremeperl@yahoogroups.com, Chris Winters <chris@c...> wrote:
                            > Sounds like a call to delurk. I agree with Rob and Rob but more for
                            the
                            > reason that having an immutable rule like "the second time you
                            > encounter functionality you MUST put it in one place" doesn't work
                            as
                            > well as ....

                            But if you double-check my original posting to this thread, you will
                            see that I did not call for "an immutable rule." I described instead
                            "[m]y own personal rule of thumb".

                            From the American Heritage Dictionary via dictionary.com: "Rule of
                            thumb": "A useful principle having wide application but not intended
                            to be strictly accurate or reliable in every situation."

                            jimk
                          • Chris Winters
                            ... I was reacting more to Terrence s shock and disbelief that copy-and-paste wasn t entirely evil. Didn t mean to misattribute. Chris -- Chris Winters
                            Message 13 of 17 , Apr 2, 2005
                              On Apr 2, 2005, at 3:16 PM, Jim Keenan wrote:
                              > But if you double-check my original posting to this thread, you will
                              > see that I did not call for "an immutable rule." I described instead
                              > "[m]y own personal rule of thumb".
                              >
                              > From the American Heritage Dictionary via dictionary.com: "Rule of
                              > thumb": "A useful principle having wide application but not intended
                              > to be strictly accurate or reliable in every situation."

                              I was reacting more to Terrence's shock and disbelief that
                              copy-and-paste wasn't entirely evil. Didn't mean to misattribute.

                              Chris

                              --
                              Chris Winters
                              Creating enterprise-capable snack systems since 1988
                            • Rob Kinyon
                              ... I think that this applies more to languages like C or Java where runtime function generation isn t possible. In Perl, Javascript, and other functional-like
                              Message 14 of 17 , Apr 3, 2005
                                > There's also a rather subtle problem that exists when you have code
                                > that is identical but represents different rules that may diverge in
                                > the future. My caffeine-deprived brain can't think of an example right
                                > now,

                                I think that this applies more to languages like C or Java where
                                runtime function generation isn't possible. In Perl, Javascript, and
                                other functional-like languages where eval and closures exist, being
                                able to abstract a function's structure means that refactoring can be
                                done based on both identical rules and identical structure, but
                                different rules. So, I'm giong to disagree with this here, Ovid.

                                But, because you have this power, it is important to use it wisely.
                                So, in languages where eval and closures exist, I would argue that you
                                -definitely- have to wait until the third copy before refactoring.

                                Rob
                              • Adrian Howard
                                ... I ll make it 7 and 4 since I m not dogmatic about either. I probably lean towards the refactor-at-first-sign-of-duplication camp. However there are
                                Message 15 of 17 , Apr 7, 2005
                                  On 2 Apr 2005, at 18:46, Curtis Poe wrote:

                                  >
                                  > On Apr 2, 2005, at 9:34 AM, Tom Vilot wrote:
                                  >
                                  >>> Against: 2 (Jim, Terrence)
                                  >>> For: 4 (Rob, Rob, Chris, Johan)
                                  >>
                                  >> five, actually. Count me in the 'for' list.
                                  >
                                  > May as well make it six. I used to think the "never duplicate" rule
                                  > was good and sometimes the second time I do something I refactor on the
                                  > spot, but I've been bitten too many times by a quick refactoring only
                                  > to realize I didn't have a full grasp of what needed to be refactored.
                                  > 3 or more times is a good rule of thumb.

                                  I'll make it 7 and 4 since I'm not dogmatic about either. I probably
                                  lean towards the refactor-at-first-sign-of-duplication camp. However
                                  there are certainly plenty of times where my small brain has no idea
                                  the direction the code is going so I let the code tell me what it wants
                                  to do by waiting for a few more examples.

                                  Adrian
                                • Adrian Howard
                                  On 7 Apr 2005, at 08:36, Adrian Howard wrote: [snip] ... [snip] And the quote of the day site gave me this today. Never express yourself more clearly than you
                                  Message 16 of 17 , Apr 7, 2005
                                    On 7 Apr 2005, at 08:36, Adrian Howard wrote:
                                    [snip]
                                    > However
                                    > there are certainly plenty of times where my small brain has no idea
                                    > the direction the code is going so I let the code tell me what it wants
                                    > to do by waiting for a few more examples.
                                    [snip]

                                    And the quote of the day site gave me this today.

                                    Never express yourself more clearly than you are able to think.
                                    - Niels Bohr (1885 - 1962)

                                    :-)

                                    Adrian
                                  Your message has been successfully submitted and would be delivered to recipients shortly.