Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re: Re: Simplifying code (Not obfuscation)

by 2mths (Beadle)
on Mar 04, 2003 at 11:19 UTC ( #240290=note: print w/replies, xml ) Need Help??


in reply to Re: Simplifying code (Not obfuscation)
in thread Simplifying code (Not obfuscation)

A refreshing and totally unexpected tone of reply. I often see comments about more than one way..., but often there does seem to be a preferred way and/or a best practise way.

I have already read the strict/warnings node and commented in agreement with it (My first post actually). I do use warnings but must admit that I don't tend to use strict. I'm trying to get myself into the habbit of doing so for 'production' code.

In terms of testing the result of system would something like the below be appropriate?
if ($var = `system thingy`) || die "Failed to get return from call to system\n";

Thanks for the comments, encouragment and suggestions.

Replies are listed 'Best First'.
Re: Re: Re: Simplifying code (Not obfuscation)
by zakb (Pilgrim) on Mar 04, 2003 at 11:29 UTC

    Well for me, maintainability should be one of our highest concerns as developers: will the developer who follows me understand my code? But that's probably a good subject for a meditation later!

    You're close with catching the error; this should work:

    $var = `...` or die "System failed: $!\n";

    Basically, you don't need the if; the left hand side of the expression will be undef (false) if it fails, so the or will evaluate the right hand side. You'll see this form of error catching quite a bit, especially when using open and the like to operate on files. Note the use of $!, which will tell you what the system error message was - see perlvar for more information about this.

      Fantastic reply!

      Explanation of such things as: Use of if, or and $! greatly appreciated. One of those posts that makes brings together lots of snippets from here and there to create something far greater than the sum of it's parts.

      If I can vote for this reply I will, though it'll have to be tomorrow, my 5 for today have been spent.
Re: Re: Re: Simplifying code (Not obfuscation)
by Molt (Chaplain) on Mar 04, 2003 at 11:35 UTC

    Your test is mixing two different kinds of conditional, the 'if' and the 'or' types.

    If/Unless version:

    unless ($var = `system thingy`) { die "Failed to get return from call to system\n"; }

    Or version:

    $var = `system thingy` or die "Failed to get return" from call to syst +em";
    Note the use of 'or' instead of ||. The only difference between them is their precendence, but as a result the 'or' doesn't need the braces round the assignment.

    Overall good coding style. Nice and readable. If all the code I had to do maintenance on was so readable I'd be a very happy bunny.

    Update: Changed the if to an unless since I totally messed up the logic. Oops. Thanks 2mths for pointing that out, shall try and engage brain earlier next time.

    Update: Fixed the missing ` problem. Thanks parv. Also updated brain to test all Perlmonks submissions to avoid silly mistakes like this in future.

      Again, a very welcome and highly appreciated post, highlighting to me the existance of and difference between "if" and "or".

      I won't pretend to understand the meaning of precedence in this context but I don't think that stops me understanding the pertinent points of your post.

      That said, looking closely at the if solution I would have thought that would die if the system call actually succeeded. Am I missing something?

        No, you're quite right. I was being stupid and messed up, will correct that in a second so as not to confuse others.

        The precedence issue is moderately easy to explain in this context. There's a standard Perl idiom

        open FILE, "file.txt" or die "Error: $!\n".

        This is the equivilent to

        open (FILE, "file.txt) or die "Error: $!\n"

        as the 'or' is evaluated after the open command.

        If you were to try

        open FILE, "file.txt" || die "Error: $!\n"

        you may be surprised to know you'll never get the error message, this is because the || operator is evaluated before the open and so this is actually equivilent to

        open FILE, ("file.txt" || die "Error: $!\n")

        and so would only die if the string literal "file.txt" was blank. Not good. You get a similar thing with thing happening quite often.

        Moral of this story: Generally use || for defaulting values ($a = $b || $c), but use 'or' for logic control similar to the above.

        Oh yeah, and make sure your code dies when it gets an error, not when it doesn't.. I seem to have failed on this one

      Molt, the unless version will not work due to missing "`" in the condition.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (5)
As of 2022-10-04 12:32 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My preferred way to holiday/vacation is:











    Results (17 votes). Check out past polls.

    Notices?