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

I have a interesting question.
I now have to maintain a large application that requires many scripts. All the code was written without the benefit of strict and scope is only referred to before 11am.
Is there a game plan for moving strict in over a period of time when you can't afford down time?
I feel that once I get the code cleaned up, I can make sure people keep it clean, I am just having trouble wrapping my head around how to get started.
The code is so large, that if wrapped each function used from another script in strict and no strict I fear I would make MORE of a mess then actually leaving things as is.

Thanks for your time!

Replies are listed 'Best First'.
Re: Implementing strict on shoddy code
by Yohimbe (Pilgrim) on Feb 10, 2001 at 08:29 UTC
    You've got quite a task on your hands. I've done this very task. I started by doing the obvious: use strict in the main routines. That, of course, boned the code. So i tried the opposite approach: starting from the libraries. I added use strict to library routines. It was slightly easier to have the code continue to work when coming from that direction. Also, it let me understand data flow in the code.
    Then I did some more ambitious things: I found common subs and put them into a proper Library_name.pm file, and started to 
    use Library_Name qw(/subroutine_i_needed/);

    [download]
    This then took me the next couple steps. I started with use strict in the library.pm file, and I could start making the interfaces more like a properly built system. I didn't go all the way to object perl, the system did not really lend itself to that, but it did let me go to use strict fairly quickly.
    Worst part was the templating code. it relied on eval's and globals. Very ugly. I ended up replacing the whole template stuff with some generic code that (later) I found was similar to the CPAN Templating stuff.
    --
    Jay "Yohimbe" Thorne, alpha geek for UserFriendly
[reply]
[d/l]
Re: Implementing strict on shoddy code
by AgentM (Curate) on Feb 10, 2001 at 08:29 UTC
    Here's the game plan: Copy ALL of the perl scripts you wish to convert into a new directory. Convert and test throughly test each script (though less thoroughly than you did before since now you have the benefits of strict and warnings, right?). You'll know then when you're done, you can copy and overwrite those old scripts.

    Typical pitfalls of conversion- remember:

    • predeclare your variables
    • keep the rules of strict references (good programming usually implies this)
    Good luck!
    AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.
[reply]
Re:(2501- further clarification) Implementing strict on shoddy code
by 2501 (Pilgrim) on Feb 10, 2001 at 08:58 UTC
    Part of my problem is....half the programmers WANT to use strict but can't see a way of implementing it, the other half have never been exposed. Managers would see it as a loss of productivity to devote time solely to getting another development copy going and working to get it cleaned. The management point of view is "It runs, therefore it does not need to be fixed. Fixing something that executes is a loss of productivy, hence forbidden."
    All the code will eventually get cycled through naturally over time. I was maybe wishing too much for a solution where as those familiar with strict cycled through the code, they could clean as they modified, upgraded, replaced, etc.
[reply]
      Data point. I find when dealing with anything over 50 lines that by adding strict and then correcting the errors that it reports I usually figure out the code faster than trying to read it. Normally in the process I find a few bugs (often including the original one) and if I don't get the one that I am after I have at least learned the code well enough to guess where it is.

      Therefore adding strict as part of trying to debug reported problems may be a workable strategy.

[reply]
      If your management does have half a point. If the code isn't broken, why fix it? From the standpoint of making development cycles count, cleaning up working code isn't a good move, at least not on the surface.

      So, wait until you do need to fix it. As soon as any maintenance is done on one of the scripts, the "exit criteria" include use strict;

      If, over time, the code will get "cycled" (I assume you mean "recycled") then make use strict; a criteria for any new code. The people on the team who haven't gotten the religion will get their chance then.

      patience is the magic formula here.

[reply]
[d/l]
[select]
        If the code isn't broken, why fix it?...
        Because there are two kinds of broken, "not working now" and "waiting in the bushes for you". Just because it works doesn't mean it isn't broken. It just means that you can't see how it is going to fail right when you need it the most.

        One of my earliest big perl scripts was an ISP signup form. It wasn't broken at all until some jerk wanted a "$" in his friggin' login name. =) And then, it was horribly, horribly broke...

        --
        $you = new YOU;
        honk() if $you->love(perl)

[reply]
      I more or less learned Perl on the job use strict; was impressed upon my frontal lobes from script one: If you see a script of mine which uses neither warnings nor strict you can be at least fairly certain that the output is 'Just Another Perl Hacker'.

      Elgon

[reply]
[d/l]
      In attempts in learning to use strict, I came across an odd phenominon that may help in this situation. I have a controlling file using many different requires as the situation demands. Adding use strict to one of the requires returned the usual strict errors for the file required, but not for the controller or any other files required. This occured using ActivePerl Build 618 (Perl 5.6) running on a Win2K box. Using this, so long as one's software is broken down into manageable subroutines, as needed each one can be moved into a file with use strict and required. The subroutine can then be made strict, leaving the rest still in it's original state. To test this, I used the following code : 
      Controller --

#!perl

$x = 5;

print "Before Require $x\n";

require('e:/perltest/require.cgi');
&MoreTest;

sub MoreTest {
  $y = 6;
  print "After Require $x, $y\n";
  
  &TestPrint();
  
  print "After TestPrint $x, $y, $z";
}



REQUIRE --
#!perl

use strict;

print "In Require\n";


sub TestPrint {
  my $z = 10;
#  print "$x $y ";
  print "$z\n";      
}
1;

      [download]
      If you uncomment the print statement in TestPrint in the require, you will get the strict errors, while the in the controller, you see the vars $w and $z are not defined yet still recieve no errors. I hope this information helps Dave
[reply]
[d/l]

Back to Seekers of Perl Wisdom