Re: Test Number of Elements In Array

[liverpole]

Hi walkingcow,

Adding my 2 cents here ...

A trick I like for comparisons against a constant (for both arrays and scalars), is to put the constant on the left side of the == operator.

This has the nice effect of making it illegal to accidentally drop one of the '=' signs.

For example, in:

use strict;
use warnings;

my @array = ( 1, 2, 3 );
print "@array\n";

# Time passes...

if (@array = 10) {       # A typo -- should have been "(@array == 10)"
    print "@array\n";    # Causes an assignment, and a TRUE evaluation
+!
} else {
    print "The array doesn't have 10 values\n";
}

# Prints:
#   1 2 3
#   10


@array = ( 1, 2, 3 );
print "@array\n";

# Time passes...

if (10 == @array) {      # Can't accidentally do "(10 = @array)"
    print "@array\n";    # without getting a fatal error.
} else {
    print "The array doesn't have 10 values\n";
}


# Prints:
#   1 2 3
#   The array doesn't have 10 values

If you were to accidentally change "==" to "=" in "if (10 == @array" (or someone in the future did the same), the resulting error would reveal it:

Can't modify constant item in scalar assignment at x.pl line 26,
near "@array) "
Execution of x.pl aborted due to compilation errors.

I use it all the time now by habit, and I never have to worry about accidentally assigning instead of comparing. Of course, ymmv...

[JavaFan]

I use it all the time now by habit, and I never have to worry about accidentally assigning instead of comparing.

The downsite is having "magic" numbers in your source code. And the trick only works when comparing against a literal, not a variable. If you write:

my $SPECIAL_SIZE = 10;
...
if ($SPECIAL_SIZE == @array) {
   ...
}

and you mistype '=' instead of '==', you're out of luck again. Now, using use constant SPECIAL_SIZE => 10; will save you, but constants defined that way aren't easy to interpolate.

As usual with programming, doing X to avoid Y compromises on Z. Personally, I prefer not having 'magic numbers' in my source code, relying on test cases to avoid the '=' typo.

[liverpole]

        "The downsite is having "magic" numbers in your source code."

One doesn't introduce any new "magic numbers", if instead of writing:

    if (@wishes == 3) {
        print "The genie has granted all of your wishes\n";
    }

One writes:

    if (3 == @wishes) {
        print "The genie has granted all of your wishes\n";
    }

        "And the trick only works when comparing against a literal, not a variable."

Granted.  But that doesn't make it any less useful to use for constants, which was my point.

Speaking of magic numbers, I think one can get too carried away with their usage.  I would argue the following goes a bit overboard ...

my $days_per_year = 365;  # In case the number of days in a year chang
+es ;-)
...
if (@calendar < $days_per_year) {
    warn "Hold on, Cinderella -- you're calendar isn't full yet.\n";
}

The above example is based on a college classmate of mine who, back in the days of BASIC, had the constant "dpy" ("Days per year") in a startup script, so when he needed it, he could type "dpy" instead of "365"!

[akho]

It's buggy no matter if you use a constant or not. Last year had 366 days.

Things change even when you don't expect them to.