Uri Guttman wrote:
>>>>>> "SB" == Steve Bertrand <st...@ibctech.ca> writes:
>
> SB> I create %typedefs hash, where each key is a name which has a value of a
> SB> coderef that simply creates and returns a hash. Then:
>
> SB> my @data_types = $vardb->is_type();
> SB> my @missing_types;
>
> SB> for (@data_types) {
>
> use named vars instead of $_. it makes the code easier to read and
> follow. you use $_ so often in this loop and i can't track what is in it
> without a name. this is a general rule you should use, avoid $_ unless
> you have to (grep/map) or it really makes things cleaner.
Testing has really helped me in a couple of ways thus far. First, it
very quickly allows me to find any problems with API changes. Second, it
it has been a godsend for being able to find and gracefully handle cases
of undefinedness so Perl doesn't have to.
In all honesty, I think I'm learning more about Perl (and my own
programs) writing the tests than I do when I'm writing the programs
themselves. (Same goes for keeping up with the documentation!).
Given your comments above, would you say that this is better?
my %typedefs = (
plan_info => \&plan_info,
user_info => \&user_info,
plan => \&plan,
...etc...
);
...
my @known_types = $vardb->is_type();
my @missing_types;
my %data;
for my $known_type (@known_types) {
unless (exists $typedefs{$known_type} ) {
push (@missing_types, $known_type);
next();
}
%data = &{ $typedefs{$known_type} };
eval { $sanity->check_type( $known_type, \%data, $error ) } ;
unlike ( $@,
'/not a defined datatype/',
"$known_type is a valid and available data type"
);
}
print "\n";
is (
scalar(@missing_types),
0,
"All known data types have been tested for existence"
);
fwiw, $sanity->check_type() checks only whether the type is valid. There
is another method that compares to ensure that the input data matches up
key-wise with the defined structure. I've separated these two methods
and aggregated them into a higher level call so I could test separately.
By testing this way (and testing in general), I've been very able to
specify error messages that are extremely precise, as opposed to generic
ones. It's much more fun when I can read one of my error messages and
know exactly where the error is triggered from in the six level stack
trace ;)
> why are you single quoting '$_'? that will be the literal $_ and not
> what is in $_.
Because I simply replaced a bareword string with the default var, and
forgot to remove the single quotes.
Cheers,
Steve
smime.p7s
Description: S/MIME Cryptographic Signature
