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


in reply to Use strict warnings and diagnostics or die

Yup mpolo, I agree it is too long. Waay tooo long. I got totally manic and let my fingers go wild for a hour or so. As with the original New Monks which got pared down to the New Monks Info Page this page needs a serious edit.

The problem is that use strict is a pain when you first use it a it breaks working code. Hell my sysadmin advised me not to use it! From a new user's perspective the obvious question is "Why do I need to use strict, it breaks my working code?"

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. To short and you lose the explanation, to long and you lose the readers interest. Kinda Catch 22.

Having now had 24 hours to sleep on it I will get out the axe and hack out all the bits that can wait trying to distill a bare essence of truth out of this. When it's done I'll post it with a link to the full version here. I've had plenty of /msg feedback on what can go but welcome more suggestions of what to keep and what to axe. Another perspective always helps you know...

Yes I like XPs as much as the next Monk. IMHO the tangible reward (via XPs) for the help we all offer is what makes this site so much more rewarding and fun than usenet. At the Monastery even if no one posts a thank you or sends a /msg vis same you get some positive (or negative) feedback on your efforts. As well as promoting a helpful flame free attitude the fact that you can get -ve XPs (and generally do for posting a RTFM reply) encourages friendly behaviour from the Monks and makes for a much more pleasant environment for all of us.

Off to sharpen the axe

cheers

tachyon

Replies are listed 'Best First'.
Re: Re: Use strict warnings and diagnostics or die
by jonadab (Parson) on Jan 27, 2003 at 12:18 UTC
    > 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

      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

        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

Re: Re: Use strict warnings and diagnostics or die
by Sector0 (Initiate) on Feb 15, 2003 at 08:18 UTC

    I do not agree with Mpolo's suggestion to split this into three tutorials (entitled use strict; use warnings; and use diagnostics;). If you really feel like it needs to be broken up into smaller pages, you should start with a general overview. Then, the second (and possibly third) page(s) could cover the subjects in greater detail. Tutorials are generally geared toward newbies who do not alway benefit from all the details at once (not to say that the details should be skipped). Crawl->Walk->Run kind of thing.

    The problem is that use strict is a pain when you first use it a it breaks working code. Hell my sysadmin advised me not to use it! From a new user?s perspective the obvious question is Why do I need to use strict, it breaks my working code?

    The tutorial is designed for people without a lot of experience in Perl (i am assuming... since it is a lesson on -w, use diagnostics, and use strict). These are the people that *should* be making sure to include the warnings and diagnostic functions. Even experienced programmers new to Perl should probably enable these functions until they get comfortable with the language.