in reply to Hash code bug

firstly Secode, don't use $a or $b, they are special variables used by Perl in sorting routines/

secondly, also always

use strict; use warnings;
use strict forces you to declare any new variables with my (or similar), so you'll avoid silly typos like
my $string = "why doesn't this print?"; print $strnig;
thirdly, always quote your barewords (by default use strict forces to do this too). What I mean by this is do...
my $string = "A"; # rather than my $string = A;
If this seems petty, then look at the following.
sub A { return 'B' }; # ... 1000 lines of complicated code ... my $string = A; print "$string\n"; # this prints "B"
Without knowing that A is a subroutine you could be forgiven for think your output might be A. Save yourself, and the people who maintain your code, the effort and clear up this ambiguity and always "use strict"

using warnings will give you handy hints, like when you use a variable but haven't defined a value for it yet. A lot of it's messages can be ignored, but they'll often give you hints to potential problems with your code.

Applying all this to your script gives you...

#/perl/usr/bin use warnings; use strict; my %line; my $why = ""; my $key_a = 'A'; my $key_b = 'B'; my $key_c = 'C'; $line{$key_a}{$key_b}{$key_c}; # this is line 12 my $i = 1; for my $loop_key_a (keys %line) { for my $loop_key_b (keys %{$line{$loop_key_a}}) { for my $loop_key_c (keys %{$line{$loop_key_a}{$loop_key_b}}) { print "$loop_key_a $loop_key_b $loop_key_c\n"; } } }
Which, when run, issues the warning "Useless use of hash element in void context at rja.pl line 12.", which might have been enough of a clue for you to figure this one out for yourself.

Happy Coding!

---
my name's not Keith, and I'm not reasonable.

Replies are listed 'Best First'.
Re^2: Hash code bug
by jonadab (Parson) on Apr 28, 2006 at 13:25 UTC
    A lot of [warnings] can be ignored

    In general, warnings should NOT be ignored. There are certain exceptions (e.g., in a CGI script it is common to interpolate an input into link URLs without checking whether it is defined, so that if the user once specifies it it is subsequently preserved), but even there you should only ignore these warnings if you are certain you understand fully what is causing them, and even then it's good practice to clean them up, to make life easier when maintaining your code later (since noisy output can obscure real issues).

    If you get into the habbit of ignoring warnings, you're going to end up with a big mess down the road.