in reply to Re: Re:(2501- further clarification) Implementing strict on shoddy code
in thread Implementing strict on shoddy code

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)

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

Replies are listed 'Best First'.
Thou shalt be paranoid.
by Elgon (Curate) on Feb 10, 2001 at 12:11 UTC
    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

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