in reply to imposing "strict" on an included file

Why are you trying to do this? If the library is completely written, working and out of your control, then adding strict and warnings won't cause it to do anything it doesn't already do, except for maybe stop working in new and stupid ways. Otherwise, if the module is still in development, which is the only time strict is useful, why don't you just make whoever is developing it put strict in?
  • Comment on Re: imposing "strict" on an included file

Replies are listed 'Best First'.
Re^2: imposing "strict" on an included file
by dpuu (Chaplain) on Jul 23, 2004 at 17:53 UTC
    The files in question define tests for our hardware. In hardware testing, false-passes are the ultimate evil. A false fail can be dealt with (you just get someone to fix it), but a false-pass can make its way into production, un-noticed. Therefore, we'd far rather break modules that are currently seming to work, then to leave them with potentially hidden problems. Adding "use strict" is seen as a bit of low-hanging fruit.

    --Dave
    Opinions my own; statements of fact may be in error.

      So why not just open up the files in question and type "use strict" at the top?
        Two reasons off the top of my head: it would require all the files to be touched (and touching a file is, itself a risk); but, more importantly, it would only work for existing files. One possibility to avoid that issue would be to grep the files at the start of the test and die if "use strict" isn't found. But a simple way to say "do_strict $filename" would be more elegant.