in reply to Use of uninitialized value in string eq
Last time when I had an error of uninitialized value, I was able to fix it by simply initializing the variable.
Don't do that! Or at least, don't do that unless you understand why the variable was uninitialised and providing a default it the correct solution. Just initialising a variable to mask a warning is not fixing the bug in your code.
In a similar way, declaring all your variables up front in a block just to satisfy strict negates the virtue of using strict. In your sample code for example you use $line in a loop, but declare it outside the loop - that's bad. You declare $data then initialise it in the following line. Don't! Declare it where you initialise it.
$gi highlights the problem. It is declared up from with everything else so that strips any meaning that could be inferred from its scope. However the way it is used implies that $gi retains state across iterations of the while loop, but no check is made in the loop to see that $gi has a valid value in the $info{$gi} = $line assignment. An undef check before the assignment and die indicating a badly formatted file may save a lot of grief at some point. BTW, should that assignment perhaps be a push: @$info{$gi}, $line and the array assignments later should then be @temp = @$info{$humangi} and @value = @$info{$gi}?
I notice too that you don't chomp lines in the INFILE2 loop. Is that by design?
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: Use of uninitialized value in string eq
by sophix (Sexton) on Apr 23, 2010 at 13:02 UTC | |
by sophix (Sexton) on Apr 23, 2010 at 14:09 UTC | |
by sophix (Sexton) on Apr 23, 2010 at 16:24 UTC | |
by GrandFather (Saint) on Apr 24, 2010 at 00:02 UTC | |
by sophix (Sexton) on Apr 25, 2010 at 01:02 UTC | |
by sophix (Sexton) on Apr 26, 2010 at 02:36 UTC | |
|