Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Re^2: Avoiding silly programming mistakes

by JavaFan (Canon)
on Aug 20, 2008 at 13:35 UTC ( #705509=note: print w/ replies, xml ) Need Help??


in reply to Re: Avoiding silly programming mistakes
in thread Avoiding silly programming mistakes

{if (0 == $foo) vs if ($foo == 0)} The reason some people recommend the latter is because if you accidently type the == equality operator as the = assignment operator, you will get an error (not so for the former). Since I vary rarely get bitten by this, I still use the former.

That's a C thing; that is, a practise that was used among C programmers long before Perl programmers started coding.

It's not really necessary to do so in Perl; with warnings on, if you mistake the operator, Perl will warn (Found = in conditional, should be == at ...). I think some C compilers (like gcc) will warn if you have an assignment in a conditional as well; which can be disabled by using an additional set of parenthesis.


Comment on Re^2: Avoiding silly programming mistakes
Select or Download Code
Re^3: Avoiding silly programming mistakes
by Limbic~Region (Chancellor) on Aug 20, 2008 at 13:56 UTC
    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; }

    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

      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) { ... }

      (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()) {...}
      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) {...}
      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

Re^3: Avoiding silly programming mistakes
by Jenda (Abbot) on Aug 29, 2008 at 16:33 UTC

    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.

Re^3: Avoiding silly programming mistakes
by kyle (Abbot) on Aug 29, 2008 at 17:56 UTC

    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

    I'd rather have that than some mere warning.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://705509]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (6)
As of 2014-10-23 04:44 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (124 votes), past polls