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?
In reply to Re: Use of uninitialized value in string eq
by GrandFather
in thread Use of uninitialized value in string eq
by sophix
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |