http://qs321.pair.com?node_id=198167


in reply to I/O problems...what am I missing?

My output isn't quite what I'm expecting and for the life of me I cannot locate the problem....Any ideas?

use strict;

And the problem will jump right off the page.

Replies are listed 'Best First'.
Re: Re: I/O problems...what am I missing?
by clintp (Curate) on Sep 16, 2002 at 13:37 UTC
    use strict;
    And the problem will jump right off the page.
    I'm sorry, that's just wrong. A use strict would cause 60 completely unrelated and spurious errors to "jump right off the page" at our poor unsuspecting programmer. It wouldn't be helpful at all and probably counter-productive.

    He'd probably do what every new programmer does when they see this: declare everything with my until the errors go away. Which means he'd probably declare the wrong variable names with my too in the massive effort to track down and declare all of his variables. So in effect he'd be using strict for no good reason, waste his time, cluttered his code, and still not found his error. Looking at this script he probably doesn't need the benefits of lexicals anyway.

    Turn on warnings instead. A -w in the #! line or a use warnings would make the problem a lot more obvious. In fact, perl tells you *exactly* what the problem is. And finds another one for you as well.


    PS to the original poster: the codeopen INPUT, "a:scores.txt" || die "Cannot locate input file: $!"; has the wrong precedence and doesn't do what you think it does. Try an "or" instead of "||".
      I'm sorry, that's just wrong. A use strict would cause 60 completely unrelated and spurious errors to "jump right off the page" at our poor unsuspecting programmer. It wouldn't be helpful at all and probably counter-productive.

      Nonesense. I copied the code into an editor, looked at it for a moment, added use strict;, and it took less than a minute and a half to work through the "unrelated and spurious" errors before identifying the culprit. If he'd started off strict, he (probably) never would have had this problem.

      Turn on warnings instead. A -w in the #! line or a use warnings would make the problem a lot more obvious.

      That's good advice, after problems identified by use strict; have been cleaned up. To jump right into -w is kind of like debugging stuff at run-time that still has compile-time problems.