Yes, it is "just as bad" in my book, worse actually. The "my ... if 0" is at least clear in that it is intentional in misusing a misfeature in order to get a "static" variable (in C terms) similar to the new "state" variables.

But "my ... if ..." is worse in that it is either misusing this misfeature in a more complicated way (which makes it a worse misuse in my book), or it is not intended to use the misfeature in which case it is a likely source of bugs (which is worse than misusing a misfeature in my book).

So you should replace "my $foo= ... if ...;" with "my $foo; $foo= ... if ...;" and very carefully determine (if you are smart or lucky, by simply running your comprehensive test suite) whether the misfeature was desired.

In the unlikely event that the misfeature was desired, then you should replace the code with something more complex, such as the following code that does not require 5.010:

# Rarely, you should replace:

sub foo
{
    # ...
    my $bar= init() if condition();
    # ...
}

# With:

BEGIN {
    my $prevBar;

    sub foo
    {
        # ...
        my $bar= $prevBar;
        $prevBar= $bar= init()
            if  condition();
        # ...
    }
}
[download]

Hopefully, you will follow that with some refactoring which will make the code clearer. Bah, that puts too little emphasis on the more likely correct replacement so let me repeat it below more verbosely.

# Usually, you should replace:

    my $bar= init() if condition();

# With:

    my $bar;
    $bar= init()
        if  condition();

# or even:

    my $bar= condition() ? init() : undef;
[download]