Re^3: Avoiding silly programming mistakes

JavaFan,
It's not really necessary to do so in Perl...

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.

Cheers - L~R

Comment on Re^3: Avoiding silly programming mistakes Download Code

Replies are listed 'Best First'.
Re^4: Avoiding silly programming mistakes by moritz (Cardinal) on Aug 20, 2008 at 14:04 UTC
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) { ... }`).	[reply] [d/l] [select]
Re^4: Avoiding silly programming mistakes by JavaFan (Canon) on Aug 20, 2008 at 14:11 UTC
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.	[reply] [d/l] [select]
Re^5: Avoiding silly programming mistakes by Limbic~Region (Chancellor) on Aug 20, 2008 at 14:48 UTC
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	[reply]