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

Re[2]: [XP] Zen Refactoring

Expand Messages
  • Tony Byrne
    Hello Ron, RJ I once saw Kent Beck do that in a most amazing way, but I haven t RJ learned the trick of making code look similar prior to removing RJ
    Message 1 of 42 , May 31, 2005
      Hello Ron,

      RJ> I once saw Kent Beck do that in a most amazing way, but I haven't
      RJ> learned the trick of making code look similar prior to removing
      RJ> duplication;

      I find I can do this easily with relatively simple code, but there are
      other times when it feels it should be easy but isn't and I'm left
      scratching my head. In that respect it reminds me of algebra.

      RJ> would love to see an example.

      As a TDD kata, I recently implemented a small program to convert
      integers to a string representation in words. (e.g. 1 --> one, 55 -->
      fifty-five). For me, this problem contains one example of duplication
      which was easy to make disappear once the duplicated code was made
      similar, and one where no matter how I look at it, I can't make the code
      similar enough to make the duplication disappear.

      I don't have source code for the intermediate stages, so I'll work
      from memory. As I TDD'd, I evolved code that handled the suffix for
      each of the orders of magnitude (hundred, thousand, million, billion)
      with what was effectively a switch. As I refactored the code, I
      replaced the switch with code that uses a hashmap to lookup the proper
      suffix (hundred, thousand, etc.) for each order of magnitude. The
      original switch also handled the decision for determining the
      concatenator to use for joining up the sub-strings of the answer i.e.
      ', ' and ' and '. I was able to re-arrange the cases of the switch so
      that they handled the appending of the concatenator in the same way. I
      then factored out that concatenator code to a method. This made the
      cases similar enough that I could move to replace the switch with a
      lookup and a tiny fragment of code. So far, so good.

      The more 'troublesome' duplication case is the obvious similarities
      between the code that handles the sub one-hundred integers and the
      more general code that handles all other orders of magnitude. Both
      have code that splits the bit to be converted into two parts using
      modular arithmetic, but they deviate sufficiently in how they process
      the parts that the duplication remains.

      I can post real code if required, but be warned it's Perl. I'm not
      actually looking for an answer, but maybe the example is worth
      pursuing in the "Look! real code!" sense.



      Tony Byrne
    • Alex Chaffee
      ... One way I ve found to avoid this is to use IntelliJ s awkwardly named Replace Method Code Duplicates refactoring. It looks for all blocks of code that
      Message 42 of 42 , Jun 4, 2005
        On 6/1/05, Elizabeth Keogh <ekeogh@...> wrote:
        > I've extracted a method from a test, then applied the extraction to a
        > similar chunk in another test, but missed out one of the parameters which
        > made it different.

        One way I've found to avoid this is to use IntelliJ's awkwardly named
        "Replace Method Code Duplicates" refactoring. It looks for all blocks
        of code that have the same structure as the contents of the method,
        and replaces them with a call to that method. It's the natural
        successor to Extract Method -- perhaps a better name would be "Apply
        Method". It's not perfect, but when it works it's a thing of beauty.

        Yesterday it saved us from just the problem you mentioned. We tried to
        apply it and it *didn't* select the code we thought it would; it
        turned out we'd missed a parameter. Once we introduced that parameter
        it worked. If we'd been doing this by hand we'd have made your

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