Probably why I have never adopted it. That doesn't mean that there aren't people out there recommending it. For those following along at home, perl doesn't always issue a warning with the assignment operator in a conditional:

#!/usr/bin/perl
use strict;
use warnings;

if (my $foo = foo()) {
    print "No warning\n";
}

if (my @asdf = (1..5)) {
    print "No warning here either\n";
}

if (my $bar = {one => 1}) {
    print "Look Ma, no warning\n";
}

while (my $rec = <DATA>) {
    # ...
}

sub foo {
    return 42;
}
[download]

Of these, the only suspect one is the first and perl assumes you know what you are doing. Writing it with the operands reversed would have generated an error (assuming no lvalue attributes) but I agree, this is a stretch.

You have re-inforced my two points. A lesson learned the hard way is learned best and there is no substitute for experience but figuring out how much of other's experience to rely on is tricky.

If you even declare a variable, it would be nonsensical to warn when you assign to it. It's more the other way round:

if (my $x) { ... }
[download]

(variable declaration in a conditional without assignment) could actually warn, because it will never be true. (But perl intentionally doesn't have such warnings, some people like stuff like if (0) { ... }).

All your example have a declaration in the test; so it seems more likely you want to do the assignment than the comparison.

However, Perl doesn't warn on

    if ($foo = foo()) {...}
[download]

This is actually a common idiom, so it would be wrong for Perl to warn. Note that swapping the arguments around won't help you either:

    if (foo() = $foo) {...}
[download]

may be valid (if foo() returns an lvalue). And whether it's valid or not is something you only know at run time - at compile time Perl cannot know whether foo returns an lvalue or not. So at best, you get a run-time error.

And if you want to compare two variables, there's no defense against mistyping '==' as '=', as both if ($foo = $bar) and if ($foo == $bar) is common.

JavaFan,
I really don't mean to sound flippant but did you even read my node?

I was showing that perl doesn't issue a warning any time it sees an assignment in a conditional - only when it makes sense. This was intended for others reading along, not for you since you obviously know what you are talking about.

This is actually a common idiom, so it would be wrong for Perl to warn. Note that swapping the arguments around won't help you either: ... may be valid (if foo() returns an lvalue).

Yep, exactly what I said. Perl assumes you know what you are doing and when flipping operands, an error would happen unless there was an lvalue at play.

Cheers - L~R

Some compilers do. Some compilers do not tell you a thing "'cause you should use lint". Get used to the former and if you happen to come across the other you end up wasting hours of time. Luckily it did not take me so long when I was asked to make some changes while doing the "Unix and C I." exam several years ago after only ever using Borland C for a bit. The fact that there was just a single plain old textmode terminal with vi or pico to do anything with did not help a bit.

I like the if ( 0 == $foo ) construct over if ( $foo == 0 ) because the s/==/=/ typo is an error in the first but not the second.

Can't modify constant item in scalar assignment
[download]

I'd rather have that than some mere warning.