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

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

Expand Messages
  • 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 1 of 17 , Apr 2, 2005
    • 0 Attachment
      > 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 2 of 17 , Apr 2, 2005
      • 0 Attachment
        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 3 of 17 , Apr 2, 2005
        • 0 Attachment
          > 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 4 of 17 , Apr 2, 2005
          • 0 Attachment
            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 5 of 17 , Apr 2, 2005
            • 0 Attachment
              --- 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 6 of 17 , Apr 2, 2005
              • 0 Attachment
                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 7 of 17 , Apr 3, 2005
                • 0 Attachment
                  > 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 8 of 17 , Apr 7, 2005
                  • 0 Attachment
                    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 9 of 17 , Apr 7, 2005
                    • 0 Attachment
                      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.