Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re:(2501- further clarification) Implementing strict on shoddy code

by 2501 (Pilgrim)
on Feb 10, 2001 at 08:58 UTC ( [id://57571]=note: print w/replies, xml ) Need Help??


in reply to Implementing strict on shoddy code

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.

Replies are listed 'Best First'.
Re (tilly) 2:(2501- further clarification) Implementing strict on shoddy code
by tilly (Archbishop) on Feb 10, 2001 at 09:15 UTC
    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.

Re: Re:(2501- further clarification) Implementing strict on shoddy code
by dws (Chancellor) on Feb 10, 2001 at 10:00 UTC
    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.

      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)

        I'd have to go with extremely here.

        It is something I have never truly understood but the basic fact is that things will tend, in the course of time, to go tits-up: Call is the second law of thermodynamics, call it bit-rot, blame it on Bill Gates; whatever - Systems that once worked well can for no readily apparent reason stop working.

        Of course, there is always a reason: It just isn't immediately obvious. The problem is that when you start working on sufficiently large and complex systems - such as something like a bunch of CGI scripts running off a database, so not terribly large - silly little things in the code can cause what was once a nice system to stop being so happy.

        Example: If your code is run as a cron-job, for example, and does something like file-archiving or logging and it hits a snag you might not notice until, three weeks and several hundred/thousand/hundred-thousand log entries later when you really need something urgently. Then you notice that those last three weeks your script has been appending just so much garbage to your nicely comma-delimited file.

        While I don't really mean what I have written in the title (except for publicly available CGI, where paranoia isn't the problem, it is a lack thereof) for business applications you have to write and maintain in a defensive manner.

        Elgon

        Another "been there" to extremely
        My first big Perl project was fairly complicated and then I went to other things. I had left some code in that didn't do anything but generate a lot of data. The data interpretor wasn't done. There were other parts that were badly designed, etc...
        The person that took over me, didn't do anything to the code and forbid his co-worker to touch it.
        I wound up back in that area. Ouch. Nothing worse than looking at your old code. It still ran, but some of the parsing wasn't happening correctly and some errors were happenning, but they were stealth errors.
        Sometimes it just looks like it's running.
Re: Re:(2501- further clarification) Implementing strict on shoddy code
by Elgon (Curate) on Feb 10, 2001 at 09:54 UTC
    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

Re: Re:(2501- further clarification) Implementing strict on shoddy code
by dfog (Scribe) on Feb 12, 2001 at 01:24 UTC
    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;
    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

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others taking refuge in the Monastery: (4)
As of 2024-03-29 01:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found