Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re: Re: Rewriting some code

by Fingo (Monk)
on Feb 18, 2001 at 21:40 UTC ( #59267=note: print w/replies, xml ) Need Help??


in reply to Re: Rewriting some code
in thread Rewriting some code

Well since I designed the code while I wrote it some of the most important parts did not fully work with each other since I did not plan out their interaction fully. Also I have about 4 pairs of subs where the diffirence between the pair is in one symbol(+ or -)! There is also a subroutine that has to find the integer componenent of a quotent, I did not kow I could do this in one line, so I subtracted the rmainder I would get from the divident and then divided it by the diviser!I figured this code is beyond saving anyway

Replies are listed 'Best First'.
Re: Re: Re: Rewriting some code
by salvadors (Pilgrim) on Feb 18, 2001 at 21:52 UTC

    Well since I designed the code while I wrote it some of the most important parts did not fully work with each other since I did not plan out their interaction fully.

    I have to admit I find this difficult to believe. Why did you need to plan out their interaction? If you coded their interaction for one thing, and it didn't work properly, then that's not a planning issue, it's a coding issue. So why would it be any different for other interactions?

    If you need to add another interaction, and the previous code doesn't fully allow that, then rewrite the previous code to continue doing what it used to do, whilst also allowing what you now need to. This is the essence of refactoring.

    Also I have about 4 pairs of subs where the diffirence between the pair is in one symbol(+ or -)! I figured this code is beyond saving anyway

    Not at all. The standard way of dealing with these pairings (say sub do_a and sub do_b) is to create sub do_c which is the 'more correct' version that will cope with both versions, taking whatever parameters you need to supply to ensure it does the right thing.

    Then, once that is tested, you change sub do_a and sub do_b to delegate to sub do_c in the correct manner.

    Then, once you've tested this, you can step through the remainder of your codebase, either now or over any period of time you like, changing all instances of do_a and do_b to the relevant do_c calls.

    When you think you've them all cleared out you can change do_a and do_b to issue warnings, or even die, if they get called, just to make sure, and eventually remove the subs.

    The speed at which all this can happen depends on the size of your codebase and the time you've got to do all the tidying up after yourself. But stages 1 and 2 are fairly straightforward, and they're all that are required to ensure that your code still runs correctly. Everything after that is just tidying up.

    Sometimes it's definitely good to start from scratch ("build one to throw away", and all that), but there's very little code that's beyond saving, and the skills you can develop through saving unsaveable code can come in handy when you need to maintain code that you can't just start again from scatch!

    Tony

      I am sorry, but I have a lot of sympathy for the original poster. It can be easy to write an API that exposes enough about your implementation that it is very hard to later on change it. This can lead to much pain down the road.

      If you want to have code which can be refactored, you want to from the beginning expose as little in your interfaces as you can. Your components should be very simple black boxes that are easy to understand, easy to code to, and which leave you with the flexibility to change your mind later about how that section works when (not if) you find out about your original implementation mistakes.

      For more on this, pick up a good book on programming technique (my usual recommendation, Code Complete, would be a good choice) and read up on information hiding. For a couple of more data points, one of the best points that was made in The Mythical Man-Month is that the hardest class of bugs - and the one that causes the most trouble in large systems - occurs at interfaces. Also see Theo's comments on how poorly understood interfaces contribute to bugs and security holes.

      The moral? Regard every interface you expose as a chain around your neck. Avoid dependencies. And the fact that you can reach into a library and abuse some piece of knowledge about the implementation does not change the fact that doing this is generally a horrible idea.

      FIxing all of these and other other errors would mean scrapping almost everything anfd it still woulden'tr work too well.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (3)
As of 2020-10-27 06:35 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My favourite web site is:












    Results (256 votes). Check out past polls.

    Notices?