in reply to Best way to fix a broken but functional program?

I'd run it through perltidy (on SourceForge, I believe) first, so the structure is workable. You might also use B::Deparse, to get it it something resembling actual code. Then read it. All of it. Print it out and mark it up, if necessary. 4000 lines translates to ~60 pages, at 8 point font. That's not too awful.

Having read it, you might have noticed duplications or near duplications. There's your chance to factor out common code into subroutines. This also allows you better encapsulation -- you can use lexicals instead of globals, passing in and receiving data. The program will get shorter and shorter, as you do this.

Based on my experiences reworking File::Find (soon, soon), you may be able to cut out 25% or more of the code.

(Extra free advice: wouldn't it be nice if this old code had unit tests, so you could change things and verify it still performed as expected? Someday, your code will be maintained. Make life easier for someone else.)

  • Comment on Re: Best way to fix a broken but functional program?

Replies are listed 'Best First'.
Re: Re: Best way to fix a broken but functional program?
by idnopheq (Chaplain) on Aug 22, 2001 at 22:47 UTC
    THX, chromatic, perltidy looks tasty. :p

    Just from reformatting via cperl-mode, the script came down about 200 lines. But, as you say, the globals are sticky and I began replaicing pages of if-elsif code into simple switch/case statements, removing many lines of useless code.

    So far, tho, the tcpdump of the TCP/IP traffic is proving unhelpful as the Sun box and the VAXen share data amongst various processes. The Sun 2 W2K is more helpful. I can at least see what the two sides are talking about ...

    Looks like I will be able to totally redo at least half of the existing program.

    HTH
    --
    idnopheq
    Apply yourself to new problems without preparation, develop confidence in your ability to to meet situations as they arrise.

[reply]

In Section Seekers of Perl Wisdom