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


in reply to Re: Re: Use strict warnings and diagnostics or die
in thread Use strict warnings and diagnostics or die

Strict vars forces you to scope your variables. This is a very good thing. If you don't get why you have probably not read the coping with scoping link and/or worked on debugging code with over 1000 lines and wide use of globals.

Here is a very simple 'vars' typo example that will be caught by strict, will not be caught by warnings and is not 'obvious'. Typos with varnames are the statistically most common cause of software bugs....

use warnings; #use strict; my $recieved = 0; print "Do you get it (y/n)?"; $received = <>; print "Got $recieved" if $received =~ /y/;

Strict and warnings are complementary - they have some overlap but the overlap is imperfect, thus the usefulness of both comes into play.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Replies are listed 'Best First'.
Re: Use strict warnings and diagnostics or die
by jonadab (Parson) on Feb 03, 2003 at 15:14 UTC

    That's a much better example. It seems obvious to me, but I can easily see how it might not be obvious to people who don't cringe when they read "recieved". More importantly, warnings will indeed not catch it. Of course, this means typoing the same variable in the same way more than once... so it still seems somewhat unlikely to me. But it's undeniably a possible scenerio.

    I should also note that I have always been in favour of using strict in files that get used or included by other files; it was the value of using it in a regular script that I wasn't seeing.

    And yes, I have worked with code that spans multiple files and ten thousand plus lines and uses global variables (though not in Perl, and I did not use globals anywhere near exclusively). The trouble I eventually ran into was not because of this, but because the version of the language and compiler that I had been using had limits on how large the program could be, and when I reached those limits I had to try to port it to the newer version, which proved difficult, and I set it on the back burner. I've also worked with Emacs lisp, which does not have lexical scoping as far as I know (in any event, it is not much used) but solves the namespace issue another way (by making variable names longer; the convention is to prefix your names with the name of your package). It is actually important in Emacs lisp that many variables be global, because you specifically want other code to be able to dynamically scope your variables and thus alter your behavior when it calls you. It is impolite to setq another package's variable in most cases (except from .emacs of course), but you let it as a matter of course. (let in lisp is like local in Perl; AFAIK there is no equivalent to my, nor is it missed.) Then there's buffer-local...

     --jonadab

      Although the general convention is to use lower_case type varnames in Perl the case sensitivity of varnames can leadToProblems if you are using camel hump notation and have a case inseneitive Windows type background.

      Bugs related to poorly scoped common varnames like $i, $j, $count, $timeout or often $_ can be also very difficult to isolate in my experience unless you are fortunate with the bug report.

      cheers

      tachyon

      s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

        I do have a case-insensitive background (cut my teeth on PC-DOS 3.3), but while the case sensitivity in my ext3 filesystem occasionally bugs me, I have never had any trouble with case-sensitive variable names. Most of the computer languages I have used (with the notable exception of BASIC, which admittedly I did use quite a bit) are case-sensitive, so I naturally think of variables as case-sensitive.

        But your example is good nonetheless. I said that the scenerio seems unlikely to me, but unlikely is not the same as silly (which is what I formerly thought of the idea, having seen numerous flawed examples and no good ones). Other things (such as Taint mode) are higher on my list, but I now intend at some point to teach myself to use strict.

        It's odd, I came into this thread expecting not to have my mind changed, and it (at least partly) was. I went into the discussion about exception-handling expecting to have someone show me what I was missing, and having read the best explanations offered I'm now more sure than ever that I was right about that one.

         --jonadab