So what sorts of schemes do people use to avoid typos in hash keys?

use fields qw(a b c);
[download]

Dave.

What I do is treat hashkeys like radioactive waste: I handle them directly as little as possible. If I can programmatically generate them in one way or another, I do. If not, I limit my "direct contact" with them (i.e. cases where I actually type out a hash key) to a single initial typing of the key (usually as one in a list of arguments to qw). (Typing each key once is usually OK; it's when one has to type the same key more than once that troubles begin.)

For fields of hashref-based objects, I avoid accessing the hash slot directly, and define accessors instead. A mistyped hashkey won't trigger an error from Perl, but a mistyped accessor will.

If a program's design is such that multiple typing of the same key is unavoidable, I begin thinking about how to restructure the code.

This is a specific case of a general principle of software design: If you have to do something more than once, abstact it. (put a string in a variable, turn a repeated block of code into a subroutine, put identical subs in multiple scripts into a library, etc.)

I don't know how extensive your script, but if it is relatively simple, I would avoid using modules and specially designed tie's when the basic tools of the language suffice. Assign the keys to variables once and then use the variables to do hash accesses. If your real code is more complex, you might look at Hash::Util or another appropriate module, or use fields with OO accessors as was already suggested.

--DrWhy

"If God had meant for us to think for ourselves he would have given us brains. Oh, wait..."

>> I limit my "direct contact" with them (i.e. cases where I actually type out a hash key) to a single initial typing of the key...

--To address things by names, some people also use OO languages with classes and data members:-).
(Which are implemented internaly as hashes of course...:-)).

-Joe

use warnings;
use strict;
my $X;
$X->{aa} = 1;
my $c =  $X->{ab};
print "$c\n";
[download]

Yep, you sure do.

Im thinking more along the lines of when a hash key is supposed to be used in more than one place in a script and it is misspelled in one or more of them.

Note that that error is not directly because the hash key is invalid. This would produce the same error:

my $c = undef;
print "$c\n";
[download]

Anon's sample only emits a warning because it's using the bad value for something that doesn't accept undef's... but if you were doing something like the following, you would get silent failure/undesired results:

my $ct = $dbh->selectrow_array("SELECT ... WHERE x = ?",{},$c);
[download]

"Use of uninitialized value in concatenation (.) at ..." is not an error. Unfortunately...

I am used to seeing it quite often; God knows what the code around me does:-). Consider:

#!/usr/local/bin/perl -w
use warnings;
use strict;

my %report_hash = (
    'event_1_count'  => 17,
    'event_2_count'  => 53,
    'event_3_count'  => 1245,
                );

my $salary = $report_hash{'salary'};
print "Conratulations! Your salary this month: $salary dollars.\n";
print "... and my reporting Camel goes on and on...\n";

# Now, this should do it:
die "Oops... I did it again!.." unless exists($report_hash{"salary"});
[download]

    $var += 42;
[download]

One way to help me detect these errors would be to do a Dumper on the report hashref, in addition to the lightly formatted reporting that is going on during development.

I am quite anal about good programming techniques, this is just one that sometimes gets the best of me. These reporters are what i would consider on the edge of being quick and dirty / needing more formal structure - this probably means that they should probably get the more formal treatment.

Thanks for all the advice, looking forward to a weekend of studying