Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

Re: Re: Use strict warnings and diagnostics or die

by jonadab (Parson)
on Jan 27, 2003 at 12:18 UTC ( #230203=note: print w/replies, xml ) Need Help??

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

> While "Because we say so and we know Perl and you don't
> and you'll thank us all one day and we won't help you if
> you don't help yourself by doing it etc" is an accurate
> if gramatically awful response it does not explain how
> it helps. Giving short examples makes it obvious but
> adds length.

First off, in regard to length, I'm going to add my voice to those who say that strict should be in a separate document from warnings and diagnostics. That would help with the length problem, and some people such as myself who understand warnings perfectly are a big hazy on the value of strict. Splitting the thing up would make it easier to read only the needed document.

Second, I want to disagree with your assessment that the short examples make the value obvious, specifically in the case of strict. I don't have the level of experience of some people here, but I'm not exactly a complete Perl newbie either, and the value of strict (especially strict vars) is not evident to me. Further, I was under the impression from the Camel (2nd ed) that there is no consensus among the authors as to whether use strict is really useful, let alone important, and that it was kept optional precisely because some experienced people don't like it. What I still want to understand is the reasoning behind people who consider it so important, but neither the example nor the explanation helps. If anything, the example makes matters worse because any newbie can see that problem would have been caught by warnings, without any need for strict. You need an example of something warnings would not have caught, that strict does prevent, that's clearly an error but could at least potentially be hard to spot.

I want to understand what people see in strict, but this node as it currently stands isn't doing that for me.

 -- jonadab

Replies are listed 'Best First'.
Re: Re: Re: Use strict warnings and diagnostics or die
by tachyon (Chancellor) on Feb 01, 2003 at 11:59 UTC

    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.




      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...


        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.




Log In?

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

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (5)
As of 2022-11-27 18:07 GMT
Find Nodes?
    Voting Booth?