Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re^3: looking for feedback on my first script

by shmem (Chancellor)
on Jan 09, 2021 at 17:33 UTC ( [id://11126661]=note: print w/replies, xml ) Need Help??


in reply to Re^2: looking for feedback on my first script
in thread looking for feedback on my first script

Here the code is going to return the return value of sprintf(), presumably "1" which really doesn't mean anything in the context of this code.

From the docs (sprintf):

sprintf FORMAT, LIST
Returns a string formatted by the usual "printf" conventions of the C library function "sprintf".

Please elaborate how sprintf might return "1", other than as sprintf "1", as sprintf "%d", 1 or sprintf "%s",1; and how that might be the case given the incriminated statement.

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

Replies are listed 'Best First'.
Re^4: looking for feedback on my first script
by Marshall (Canon) on Jan 09, 2021 at 18:48 UTC
    Yes, you are correct in that I should have taken the time to look up Perl's exact return value from sprintf(). I fudged the issue by saying "presumably 1" - instead of something that means "true" or the exact reference to a Perl doc. In C the printf function returns the number of characters that are printed. If there is some error then it returns a negative value. There is a "succeed or failed" interpretation of this. But nobody checks the return value of printf(). In Perl, if printf() fails, a fatal error will be thrown long before it returns to the caller. I've never checked the return value of sprintf.

    We are off of my main point!
    The return value of sprintf() means nothing in this context, but it will returned absent an explicit return statement. Why return a string that the caller doesn't care about and means nothing as opposed to returning a more simple undef value? I am simply saying that I prefer having explicit return values. What your post said is "correct". Please do not take this as any real argument. We are talking about a very fine point here, not any real criticism.

    Ok, I see the situation better now.
    I would have written  return sprintf "...."
    That is just a matter of coding style. Not any real "problem".

      Why return a string that the caller doesn't care about and means nothing as opposed to returning a more simple undef value?

      Excuse me? this string is what the caller requests by calling the function create_snapshot_name() which was written for this very purpose. The calling line is

      my $snap_name = create_snapshot_name();

      in function take_new_snapshot() and the name of the variable in which this return value is stored also indicates that a string is expected as return value from that function.

      I am simply saying that I prefer having explicit return values.

      I had those discussions before, and I stick to the perl way: a subroutine returns, absent early returns, the result of the last computed expression, with or without explicit return statement. Were I to work with you having a coding policy in place which requires always stating explicit returns, I would do likewise, otherwise not.

      Edit:

      Well, depends. If I was to concoct a function dependent on context for its return value, I'd use explicit returns, sometimes setting $@ if something failed. But it really boils down to two possibilities for return values as a subroutine:

      1. I know what I have, and this is what you get, and might honour your context.
      2. take that bastard, you get what you asked for

      But then, for case 1, I would have to raise an exception if I have a list and am called in scalar context. Or should I? maybe they want just the number of elements? and vice versa.

      perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
      In Perl, if printf() fails, a fatal error will be thrown long before it returns to the caller.

      wrong

      I've never checked the return value of sprintf.

      then stop talking and read sprintf

        I disagree about printf() errors.
        With normal file operations, what I said is true. It is almost impossible for a print or printf to "fail" once a local Hard Disk file handle is open. One way would be "File system full", but in that case, a fatal exception is thrown - the calling program won't see that.

        I did make a mistake in interpreting the exact situation. I would have written: return sprintf "..." because I favor explicit return statements.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others having an uproarious good time at the Monastery: (2)
As of 2024-04-24 15:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found