artist has asked for the wisdom of the Perl Monks concerning the following question:

HI guys, I have to modify code written in 5.004_04.
I am looking for good strategies as how to handle these. I have around 100 script each performing different thing, Making database connections, processing and displaying data on web or writing in various types of files, using plenty of unix shell command as 'system' etc... I don't have to modify all these file at once, but slowly and gradually as and when needed. The modification is required only to add a new functionality or change existing functionality. It's speghetti code for sure.. It's taking time to figure out the scope of the variable etc.. in the process.
Your suggestions would be very helpful.
Thanks,
Artist

Replies are listed 'Best First'.
Re: How to modify existing code
by Beatnik (Parson) on Jun 20, 2001 at 20:31 UTC
    If it's spaghetti code, you'll probably be better of rewriting the script from scratch, something I rephrase as logic porting. Understand what it does, how it does it (file wise, system wise,...) and start hacking. The idea is ofcourse to make it cleaner, more functional, probably loads more commented, faster??, more efficient. Remember the poor guy which will need to port that same code to Perl6 :)) I doubt you'll be able to do that based on spaghetti code :) I've found it inspiring rewriting scripts from scratch over and over again (if time permits me).

    Greetz
    Beatnik
    ... Quidquid perl dictum sit, altum viditur.
[reply]

      rewriting++

      100 different scripts sounds like a nightmare (especially if you didn't write them), but I suspect that you're likely to find a lot of overlap between various scripts.

      Here's a possible sequence of events for the least painless port:

      1. As Beatnik suggests, you want to try to understand what the scripts are doing first
      2. Now try to understand what the tools the scripts need to accomplish their respective tasks are
      3. Now try to highlight areas for re-use -- e.g. database access wrappers for DBI, printing feedback to the user (either HTML, text, or graphical)
      4. These reusable elements are likely to be good candidates for either modules or objects, depending on what they do
        • Remember that objects are normally wrappers to data,
        • while modules are ways of reusing useful functions
        • This is very loose, but what I'm getting at is that in a scripting-oriented language, not everything has to be, nor should be, an object
      5. Comment, comment, comment -- how many times have you come back to your own code only to say: "What the hell was I trying to do here?"

      HTH

[reply]
Re: How to modify existing code
by cLive ;-) (Prior) on Jun 20, 2001 at 20:57 UTC
    Try to go OO/modular.

    I'm nearly there with all the concepts myself - Damian Conway's book is an absolute gem (prepare to read it several times :)

    And when I am, everything's going OO and modular for two reasons:

    • Perl6 is more OO, so planning ahead
    • keeping variables in ordered namespaces helps one hell of a lot - If you comment objects/modules well, you can amend easily without worrying about affecting code that calls it from another namespace (because that code knows the rules of your module, right :) - so, when porting to Perl6, I really hope I just have to mess around with a few modules :)

    .02

    cLive ;-)

[reply]
Re: How to modify existing code
by clemburg (Curate) on Jun 20, 2001 at 21:50 UTC

    Another approach short of rewriting all the scripts from scratch (probably not a practical approach for you) would be to write tests for the scripts.

    That way, you will understand what they do, and you will be in a position where you can change/patch/fix them without nightmares of production stopping at midnight.

    This approach has the added advantage that it looks very professional to outsiders (what rewriting typically does not do). And in fact, it is professional to do it like that. It will be a lot of work, though.

    Update: chromatic reminded me to point out that well-written tests can serve as or aid specification and documentation. Yes, this is certainly true. Thanks, chromatic!

    Christian Lemburg
    Brainbench MVP for Perl
    http://www.brainbench.com

[reply]

Back to Seekers of Perl Wisdom