Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re: A refactoring trap

by jhourcle (Prior)
on Aug 16, 2005 at 21:57 UTC ( #484260=note: print w/ replies, xml ) Need Help??


in reply to A refactoring trap

Think before refactoring!

Immediately after reading Perl Best Practices, and before, after reading Perl Medic, and countless other other books, I've wanted to go back and rewrite my code.

Luckily, I have version control, and was able to roll back everything that I broke. Don't change things just for change's sake. I know, I'm a bad one to preach on this one, as I've done 'optimizations' and 'clarifications' and such to the projects that I've worked on way too many times. Yes, it might be a one line fix, but it might introduce other subtle errors, as you found, and it may be something that you might not catch for days, weeks, or even months down the road. At that point, you can end up losing significant time from trying to pretty something up.

So, I'd say that the two rules that you should learn from Perl Best Practices apply to more than just Perl -- version control, and a good library of tests.

Now, there might be times when it's worth fixing up the documentation (I'm going to be handing off this project to someone else, and I want to make sure everything's good), or optimization (the processes is taking more than 2 seconds, and that's unacceptable).

I still cringe every time I look at some of my old code. Instead of risking breaking it, by trying to clean it up, I prefer to just go in, and make sure there's a comment at the top reflecting how long ago it was written, so if anyone starts giving me crap for it, I can point to that.

I've started working in a few of the tips from the book into my work, but if I went back and tried fixing every bad script I've written, it might take me a year, as I deal with cleaning up new messes that I'd make.

Update: Ovid's right -- I've been changing more than one thing at a time, and I haven't been running tests after every change. I guess this is one of the times when having too many tests can be a problem ... I don't mind running 5 min of tests for an install, but it's damned annoying for every 10 sec modification.


Comment on Re: A refactoring trap
Re^2: A refactoring trap
by Ovid (Cardinal) on Aug 17, 2005 at 00:56 UTC

    I've also been reading and enjoying the book. However, I have been going through and making sweeping changes in the codebase I am currently working on. Why isn't my stuff breaking? Because I am only changing one thing at a time and I'm running the tests after every change.

    I can feel confident that I am not hurting anything and I'm very confident that some of the tricky bits in my code are much easier to understand. The poor programmers who will have to go in and maintain my code may not notice it, but they would certainly have noticed some of the things that were in there before.

    In fact, I've committed my .perltidy.rc file to the code base to ensure that programmers who follow me will find it easy to at least maintain consistent formatting.

    Cheers,
    Ovid

    New address of my CGI Course.

      In fact, I've committed my .perltidy.rc file to the code base to ensure that programmers who follow me will find it easy to at least maintain consistent formatting.

      Thats a very interesting idea. Id almost like to see your perltidy.rc posted here, along with any others that folks might like to contribute. I think it would be an interesting addition to the site.

      ---
      $world=~s/war/peace/g

        Taken straight from Damian's book:

        -l=78 # max line width is 78 columns -i=4 # indent level is 4 columns -ci=4 # continuation indent is 4 columns -st # output to STDOUT -se # errors to STDERR -vt=2 # maximal vertical tightness -cti=0 # no extra indentation for closing brackets -pt=1 # medium parenthesis tightness -bt=1 # medium brace tightness -sbt=1 # medium square bracket tightness -bbt=1 # medium block brace tightness -nsfs # no space before semicolons -nolq # don't outdent long quoted strings -wbb="% + - * / x != == >= <= =~ < > | & >= < = **= += *= &= <<= &&= - += /= |= >>= ||= .= %= ^= x=" # break before all operators

        Cheers,
        Ovid

        New address of my CGI Course.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://484260]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (9)
As of 2014-07-29 09:14 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (212 votes), past polls