Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re: On Commenting Out 'use strict;'

by tlm (Prior)
on Aug 11, 2005 at 01:50 UTC ( [id://482829]=note: print w/replies, xml ) Need Help??


in reply to On Commenting Out 'use strict;'

I'm with you 100%, but let's turn the question around: what does your story tell us about how to implement our error reporting? It's a "cry wolf" story: too many trivial error messages devalue all error messages. I have noticed that, over time, perl has become increasingly smart about error messages; "false" error messages get weeded out. There's a lesson here: effective error reporting is hard work; it takes effort to get it right; the simplest solution (i.e. screaming bloody murder whenever something doesn't look quite right without investigating the matter further) runs the risk of having the receiving end stop listening. It's a two-way street: it takes effort to understand what the error messages are saying, but it also takes effort to code an error-reporting system worth paying attention to.

the lowliest monk

Replies are listed 'Best First'.
Re^2: On Commenting Out 'use strict;'
by talexb (Chancellor) on Aug 11, 2005 at 02:22 UTC

    Disagree.

    Those PITA warning messages are little hints that the craftmanship of the code is below par. Perhaps one in a thousand warnings can be ignored. The other 999 need to be addressed. An example.

    Yesterday and today I had to write quick scripts to get some stuff done on a Production system. Normally I'd do a one-liner or cobble something absolutely horrible together, cross my fingers and go with it.

    Instead, I wrote POD, used Getopt::Long to handle arguments, used or die $usefulMessage in all of the appropriate places. Yes, it took a little longer to write, and I tested as I went .. but the result was that these little utilities worked absolutely fine. Then what?

    Then I checked them into our version control system so that I would know where to find them the next time I needed them. So now I have documented, commented, error checking utilities that I can pull out of my hat (so to speak) the next time we need to do X.

    It all comes down to a matter of craftmanship. If my scripts and modules compile 100% clean, if I never have errors in my error logs, that's a sweet way to be.

    So fix your code -- banish all warnings!

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

      I think it's a little worse than that. There are a couple of warnings in Perl5 that frequently get triggered without any real problem in the code. I'm thinking most especially of the one when you interpolate a value that might or might not be defined, and it happens not to be. I have never yet once seen a situation where that warning was useful, but many, many times I have found myself introducing excessive verbosity and needless complexity to the code in order to suppress it.

      I've also occasionally been annoyed by other warnings when I knew very well about the thing they were warning about but for one reason or another did not consider it a problem, and I wished I could just make the warning shut up.

      I heard a rumor that Perl6 is going to give us the ability to shut off individual warnings, without losing the ability to see other warnings. I look forward to that.

      Nevertheless, the clown described in the original post is making future trouble for himself and/or someone else.

        I heard a rumor that Perl6 is going to give us the ability to shut off individual warnings, without losing the ability to see other warnings.

        You can actually do that on Perl 5:

        use warnings; ... # and then deep on your code { ... no warnings 'uninitialized'; # or whatever print "$uninitialized_var\n"; ... }

        I have run into more than one situation in maintaining code (one other developer, specifically) that started throwing a lot of warnings when he turned on warnings where the warning was quite useful. This person found that the best way to get rid of these "useless" "unitialized" warnings was to pipe his error logs through grep -v uninitialized. (He was not at the company six months later.) When I went into the code, I found that he was testing against a typoed hash key. This was a subtle bug that was not discovered for *YEARS* until warnings were turned on.

        Ivan Heffner
        Sr. Software Engineer, DAS Lead
        WhitePages.com, Inc.
Re^2: On Commenting Out 'use strict;'
by bofh_of_oz (Hermit) on Aug 11, 2005 at 12:49 UTC
    I would say that IMHO there are no trivial error messages: if compiler/interpreter complains, it is an error and must be fixed before sending code into production. Warnings can be commented out until all the errors are resolved; then, if you have time, deal with small things... but errors should be fixed.

    As for our own error reporting - that's for the "logical" errors that Perl cannot catch but they still lead to wrong results - yes, most definitely. That's the second thing I tend to do (after coding the functionality).

    --------------------------------
    An idea is not responsible for the people who believe in it...

      I would say that IMHO there are no trivial error messages...

      Step back for a second. What you just wrote is about as defensible as the statement "IMHO there are no bugs."

      You want to see a trivial error message? Here, stick this anywhere in your code:

      die "I'm sooo not trivial!";
      A trivial error message or warning is nothing more than a design bug.

      Consider for example the warning

      Useless use of a constant in void context
      If you read the follow-ups to Why no warnings for 1 in void context?, you'll learn that perl has a special check so that this warning is omitted if the constant is 1 or 0, or a few other esoteric values. I don't know about Larry (or whoever coded that particular bit of perl), but I'm sure that if it had been me who coded that I would have missed adding these checks first time around, and only figured that I needed them after seeing how perfectly sound code was suddenly spitting useless warnings. I.e. there is no a priori guarantee that warnings are non-trivial; this is only a function of the skill of the programmer.

      My point is that, the flip-side to the OPs observation is the burden on programmers to make their error messages non-trivial, that this also requires work, and that the more skilled you are as a programmer in keeping your error messages non-trivial, the less likely it is that users will ignore them.

      the lowliest monk

        I feel I need to clarify my statement.

        When I say "There are no trivial error messages", I mean exactly that: there are no trivial error messages that Perl gives you. I do not consider the error messages produced by or die "blah blah blah" constructs as I consider them a representation of the program logic created by a programmer who (supposedly) knows what (s)he is doing. I also specifically said that I do not talk about warnings - those are _not_ error messages, they are just that - warnings...

        What I mean is when you write a script, and run it, and Perl gives you an error message, it means there is a problem that must be fixed or the script won't run (properly|at all). It's similar to writing a resume and not doing a spell check - if it contains misspellings, it will most likely be rejected outright. Unusual grammar constructs etc. can be overlooked - spelling errors are not. Same thing in coding - warnings can be overlooked, errors should not be.

        Just my 2 cents...

        --------------------------------
        An idea is not responsible for the people who believe in it...

Re^2: On Commenting Out 'use strict;'
by harleypig (Monk) on Aug 11, 2005 at 18:38 UTC

    That's why a part of best practices should include when to turn off warnings.

    If you know a piece of code is going to produce spurious warnings; but not cause any side effects (like the 'uninitialized' that happens all the time); and doing it the correct way gives you complaints from management that it's harder to read you can just add a local $^W immediately before the code.

    Harley J Pig
Re^2: On Commenting Out 'use strict;'
by PhilHibbs (Hermit) on Aug 15, 2005 at 11:35 UTC
    I had a concise, readable, maintainable bit of C code that generated about 9 "possibly incorrect assignment" warnings, because it used assignments inside an if(). Adding parentheses made it ugly, and breaking the input out of the if would have been tricky and would not have increased the quality of the code in my opinion at the time (this was many, many years ago, and many lines of code have passed under the bridge since then, so my deicision now may be different if I still had the code). I didn't want to turn off the "possibly incorrect assignment", and the compiler (Borland Turbo C) didn't have selective warning pragmas that I could wrap the code in. So I left it as it was, and documented that the only warnings generated are this specific group.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others admiring the Monastery: (5)
As of 2024-03-28 20:34 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found