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
| [reply] [Watch: Dir/Any] [d/l] |
|
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.
| [reply] [Watch: Dir/Any] |
|
use warnings;
...
# and then deep on your code
{
...
no warnings 'uninitialized'; # or whatever
print "$uninitialized_var\n";
...
}
| [reply] [Watch: Dir/Any] [d/l] |
|
|
|
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.
| [reply] [Watch: Dir/Any] [d/l] |
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...
| [reply] [Watch: Dir/Any] |
|
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.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
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...
| [reply] [Watch: Dir/Any] |
|
|
|
|
|
|
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.
| [reply] [Watch: Dir/Any] |
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. | [reply] [Watch: Dir/Any] [d/l] |