in reply to Test Number of Elements In Array

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

[download]

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.

[download]

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

s''(q.S:$/9=(T1';s;(..)(..);$..=substr+crypt($1,$2),2,3;eg;print$..$/

Replies are listed 'Best First'.
Re^2: Test Number of Elements In Array
by JavaFan (Canon) on Jun 07, 2009 at 12:44 UTC
    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) {
   ...
}

    [download]
    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.

[reply]
[d/l]
[select]
              "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";
    }

      [download]

      One writes: 

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

      [download]

              "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";
}

      [download]

      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"!

      s''(q.S:$/9=(T1';s;(..)(..);$..=substr+crypt($1,$2),2,3;eg;print$..$/
[reply]
[d/l]
[select]
        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.

[reply]

In Section Seekers of Perl Wisdom