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.

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();
[download]

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