Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Matts (1087)

Matts
  (email not shown publicly)
I work for MessageLabs [messagelabs.com] in Toronto, ON, Canada. I write spam filters, MTA software, high performance network software, string matching algorithms, and other cool stuff mostly in Perl and C.

Journal of Matts (1087)

Wednesday December 04, 2002
01:40 PM

On refactoring...

[ #9266 ]

In conversation with a co-worker:

> [Refactoring] is like decorating a house. You sort out one place
> and give it a nice new coat of paint, and it shows up the next bit. And
> so on, until you decide to stop.

Yes, then you end up with our house. Nicely decorated, a few cracks, but
DO NOT GO INTO THE BATHROOM


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

On refactoring... 3 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • In my universe, refactoring simply means eliminate as much copy&paste as possible.

    Usually that would result in actually rewriting a lot of 'broken' things. Of course, one may always put an API layer around some crappy component, but to me that is orthogonal to refactoring.

    Or, more accurately - placing a nice API around some crappy componenet - that is not an essence of refactoring.

    Eleminating copy & paste - that is an essence of refactoring.

    http://www.xmlsuck.com/X/1037127117/index_html [xmlsuck.com]

  • Eliminating redundant code is certainly one major goal of refactoring. But it's also just about improving the readability and _design_ of the code on an ongoing basis. For example, in the Refactoring book, Fowler talks about a refactoring called "rename method". This is exactly what it sounds like.

    This won't eliminate any cut and paste, but if you have a misnamed method (or variable, or whatever) then renaming it can certainly improve code readability.
  • DO NOT GO INTO THE BATHROOM would imply an unfinished refactoring, but only in the eyes of the last refactorer.

    The problems are in my opinion really:
      - when to stop refactoring
      - when is code finished

    Postulating that code never is finished would imply refactoring can never be called complete and therefore refactoring is a tool to 'make the best of it for now'.

    My kitchen table is not fastened to the element beneath it, I can still cook and do the dishes, but I would not recommend having sev
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.