All the Perl that's Practical to Extract and Report

Warning Will Robinson

phillup on 2004-08-12T23:25:28

So, about a month ago I got all into writing test code for my modules. But, we are talking a *LOT* of code... so, I'm spending an hour or so a day to write tests of the existing code... and the rest of the day I write tests before writing new code.

I figure I'll get caught up an a year or two.
;-)

Anyways... one of the test that I wrote checked each module file (and all of my maintenance scripts) for 'use warnings'.

So, it took a day to fix all of the files and the warnings... proof positive of the need for unit testing.

Still, since I'm starting so late in the process and taking a 'piecemeal' approach to getting full test coverage (that'll be the day!)... I'm coming across many places where I get a particular warning:

Use of uninitialized value in...


Now, one hundred percent of the time (so far) that I have gotten the warning, my code has been "reasonable". In other words... there were not any "unintentional" use of the variables. For example:

my $sum;
foreach (keys %scores){
  $sum += $scores{$_};
}


Will trigger the warning, since I'm using sum without explicitly setting the value to zero before hand. But, this is Perl, and I know that it will do that for me. And... I'm lazy. Worse, I don't see the need to do it twice (once by Perl, once by me).

And, since I believe that any variable that is lexically scoped via 'my' should be considered initialized... that is just salt in the wound to me.

So... I've been wrapping those small chunks in their own blocks and doing the 'no warnings "uninitialized"' thing... But... I'm leaning towards simply making that the default for the entire module(s).

Are there any warnings that you or your company ignore as "standard practice"?

And, of course, what are the pitfalls of doing so...

warnings and incrementing

runrig on 2004-08-13T00:50:26

my $sum;
foreach (keys %scores){
  $sum += $scores{$_};
}
Any 'uninitialized' warning there isn't because $sum is uninitialized. Perl handles that fine without warning. Now, if one of the values of %scores is undefined, that's another matter :)

Re:warnings and incrementing

phillup on 2004-08-13T04:43:25

<hitting self on head>

Of course.

Hm... need to look closer at the code...

My "real" code involved string concatenation... and yes, some of the hash values are 'undef' which leads to the warning.

I didn't take that into account when writing this up.

Thank you.

Do not ignore warnings.

petdance on 2004-08-13T02:42:35

Do not ignore warnings.

Do NOT ignore warnings. The whole point of automated tests is so that you, the human, doesn't have to think about things. If you have to think "I can ignore this one, I can't ignore that one", then you're thinking.

Worse, if you ignore them, then one day there'll be another "real" warning that will be a bad thing, and you'll ignore it.

All warnings are errors.

Re:Do not ignore warnings.

phillup on 2004-08-13T05:06:20

Do not ignore warnings.

Yes, I've read your slides. And, I agree. Very much.

Which, is part of the quandry. I don't want "false" warnings drowning out the "real" ones.

But...

My gut tells me that all of these are going to be of the same class of "problem" where my programming style, doing things like expecting an undefined value to equate to zero (actually, most of it is string concatenation)... is what is causing the warning.

So... do I hunt down each individual case... change my style of programming (might as well quit using Perl if I can't use it's features!) or disable the one warning type... or something else?

Make no mistake... I definitely want my tests to alert me to real problems. And I don't want a warning to be emitted when it isn't a problem.

I'm just really trying to figure out the most efficient way of handling the problem where they specific type of warning seems to be systemic to my programming style... and not indicative of a real problem. (In all of the cases I've eyeballed so far.)

I'm also wondering if anyone else routinely disables a specific class of warnings, and why? And... what the downside has been.

Re:Do not ignore warnings.

vsergu on 2004-08-13T17:20:59

I guess it's something about your style of programming. I make use of Perl's features all the time, and I rarely run into "uninitialized" warnings. The places where I expect to be able to have undef automagically convert to '' or 0 are the places where Perl doesn't warn, but maybe I internalized Perl's ideas about when to warn a long time ago. The vast majority of times when I get an "uninitialized" warning, it's indicating a real error.

In your example, I'd have expected that undefined values in %scores were a real problem. I'd have had either 0 or no hash entry at all.