The discussion on this thread has made me recollect some of my own experiences. I had been hacking Perl for 3 years before seeing the light and discovering use strict;. There are plenty of places on this site which extoll the virtues of strict.pm, so I will not be going into details.

My initial experience was Waah! sooo many errors! But then I looked in detail at what the code was doing (all the code was 100% written by me - no cargo deliveries here :-), I realised that 99% of the errors could be removed just by inserting the keyword my. There was no need for any of the offending variables to be global.

Also, I had mastered subs' argument passing and returning quite early on (thanks to the Camel 2nd edition and Sriram Srivanam's Advanced Perl Programming), which meant I never needed to pass in values to subs via global variables. Having a Comp sci and C programming background, I instinctively felt that global variables were ugly.

I was thus able to iterate round the loop:

Edit source.pl
perl -c source.pl
understand errors 
The process, uncovered some bugs which I had no idea existed. For example, the newbie trap
my $foo, $bar;
Only $foo here is lexical. I was wondering at the time of writing the code originally, why $bar was retaining values between iterations.

The remainder of the strict errors fell into 2 categories:

Having got a clean compile on strict, I then did the same iteration loop with -w.

I recommend this approach - it's good for the soul. Also, I find that a consequence is that any new code I write, my fingers go on auto-pilot with use strict; even when coding a noddy example.

Replies are listed 'Best First'.
Re: Thoughts on revisiting old code
by vladb (Vicar) on May 16, 2002 at 13:08 UTC
    Thanks for touching the subject of using strict.pm and especially it's superb ability to fix majority of the bugs in a legacy code (that which wasn't running on strict before) without having to resort to rather involved practices such as Refactoring, for example.

    Of course, there are many other issues involved in 'revisiting old code'. Aside from having to refactor bits and pieces of an old code in order to resurrect it from near-extinction, one also has to tackle conflicting coding styles. It's half the trouble if the styles are just that 'conflicting'. Unfortunately, there's a lot of coding styles that are precursors to greater problems in the code. I believe some of these issues were touched in On maintaining old code and the battle of styles... post I mead a couple weeks ago.

    Romping around the monastery, you should also notice a great many posts where similar subjects are discussed:

    UPDATE fixed a few spelling errors ;)

    _____________________
    $"=q;grep;;$,=q"grep";for(`find . -name ".saves*~"`){s;$/;;;/(.*-(\d+) +-.*)$/;$_=&#91"ps -e -o pid | "," $2 | "," -v "," "]`@$_`?{print" ++ $1"}:{print"- $1"}&&`rm $1`;print"\n";}
Re: Thoughts on revisiting old code
by dakedesu (Scribe) on May 17, 2002 at 01:22 UTC
    Just a note: there is not strict.pm (or atleast to my knowledge) The keyword "use" is not just for loading modules. It is also used for pragmas of various kinds. Such as:
    use lib "/www/cgi-bin/modules";
    (I cannot believe I actually knew something... yeah! ^_^)
      Actually, there is a strict.pm in $PERL_ROOT/lib - and there's a lib.pm.

      It would have been a fairly daft thing for Larry to have given use a special meaning for pragmas, besides the usual meaning of #include at compile time.

        UPDATE! Okay, yes strict.pm does exist, and yes it is a pragma, as defined in the Pragmas section of CPAN. So we are both right.