Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re: How to test for empty hash?

by GrandFather (Saint)
on Aug 06, 2021 at 01:18 UTC ( [id://11135639]=note: print w/replies, xml ) Need Help??


in reply to How to test for empty hash?

Interesting. I have this thing about not doing 0 == blah because I think that reads better as !blah so I wouldn't have had the problem. In many C++ish languages the two are essentially the same so it's pretty much personal preference between an ugly verbose numeric compare and a clean succinct boolean test. In Perl, as you may have found, it can be more subtle than that!

That said, how were you performing your empty test? The simple version works fine for me:

use strict; use warnings; my %hash; print "$^V\n"; print "Empty: !\%hash\n" if !%hash; print "Empty: ! scalar\n" if ! scalar %hash; print "Empty: 0 == scalar\n" if 0 == scalar %hash; print "Empty: ! keys\n" if ! keys %hash; ++$hash{entry}; print "Not empty: \%hash\n" if %hash; print "Not empty: scalar\n" if scalar %hash; print "Not empty: 0 != scalar\n" if 0 != scalar %hash; print "Not empty: keys\n" if keys %hash;

Prints:

v5.32.1 Empty: !%hash Empty: ! scalar Empty: 0 == scalar Empty: ! keys Not empty: %hash Not empty: scalar Not empty: 0 != scalar Not empty: keys

Update: fixed mismatch between test and print for 0 == scalar

Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond

Replies are listed 'Best First'.
Re^2: How to test for empty hash?
by scareduck (Novice) on Aug 06, 2021 at 18:06 UTC
    Ah hah! This example clarifies my thinking a great deal. As I started this exercise writing a regression test, I kept having trouble inside ok() and is(). (This was using the Test2 suite, but here I will just use Test::Simple.)
    #!/usr/bin/perl use Test::Simple (tests => 9); use strict; use warnings; my %hash; &ok($^V eq "v5.32.1","Version = v5.32.1"); &ok(!%hash,"Empty: !\%hash"); &ok(!scalar(%hash), "Empty: ! scalar"); &ok(scalar(%hash) == 0, "Empty: 0 == scalar"); &ok(!keys(%hash), "Empty: ! keys"); ++$hash{entry}; &ok((%hash ? 1 : 0),"Not empty: \%hash"); &ok(scalar(%hash), "Not empty: scalar"); &ok(scalar(%hash) != 0, "Not empty: scalar != 0"); &ok((keys(%hash) ? 1 : 0),"Not empty: keys");
    This works in its entirety:
    1..9 ok 1 - Version = v5.32.1 ok 2 - Empty: !%hash ok 3 - Empty: ! scalar ok 4 - Empty: 0 == scalar ok 5 - Empty: ! keys ok 6 - Not empty: %hash ok 7 - Not empty: scalar ok 8 - Not empty: scalar != 0 ok 9 - Not empty: keys
    Thanks, all!

      As a matter of style, I would write your test something like this:

      use strict; use warnings; use Test::More; my $ntests = 9; plan tests => $ntests; { my $expected_version = 'v5.32.1'; cmp_ok( $^V, 'eq', $expected_version, "Version = $expected_version" + ); } { my %hash; ok( !%hash, "Empty: !\%hash" ); ok( !scalar(%hash), "Empty: ! scalar" ); cmp_ok( scalar(%hash), '==', 0, "Empty: 0 == scalar" ); ok( !keys(%hash), "Empty: ! keys" ); ++$hash{entry}; ok( (%hash ? 1 : 0), "Not empty: \%hash" ); ok( scalar(%hash), "Not empty: scalar" ); cmp_ok( scalar(%hash), '!=', 0, "Not empty: scalar != 0" ); ok( (keys(%hash) ? 1 : 0), "Not empty: keys" ); }

      Some points to note:

      • I always prefer Test::More to Test::Simple because that scales better as test scripts grow more complex over time.
      • At the top of your test script, you should explicitly declare how many tests your script intends to run, to protect against premature failure. I always use plan for this because as test scripts grow more complex over time you sometimes need to calculate this number.
      • I pulled a face the instant I saw your &ok() function calling style! Haven't seen that dreadful old style for 20 years! :) From Perl Best Practices: Call subroutines with parentheses but without a leading & (item 113). Update: see also.
      • Minimize the scope of variables. I find bare blocks a convenient way to do this in test scripts. Just because it is a test script doesn't mean you should drop basic standards of code quality.
      • Prefer cmp_ok to ok because you get clearer diagnostics when a test fails (see below for an example).
      • Don't repeat yourself. Test scripts are programs and you should follow the same coding quality standard in the test scripts as for the code under test. Doing this makes long term code maintenance more enjoyable and less error-prone.

      When I first ran your test script, it failed with:

      not ok 1 - Version = v5.32.1 # Failed test 'Version = v5.32.1' # at badtests1.pl line 8.
      Note that using cmp_ok instead of ok provides clearer diagnostics:
      # Failed test 'Version = v5.32.1' # at badtests2.pl line 9. # got: 'v5.32.0' # expected: 'v5.32.1'

      See Also

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11135639]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others avoiding work at the Monastery: (4)
As of 2024-03-29 06:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found