All the Perl that's Practical to Extract and Report

Navigation

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

Please Log In to Continue

The original code doesn’t make it obvious whether anything should be returned or not. Putting in an explicit return – assuming, of course, that you put it in the right place – definitely improves the code.

Perhaps that argument might be true for a longer, more complicated subroutine. I agree that implicit returns can be confusing. Perhaps a better standard would be to ban them instead of requiring unnecessary return statements. Then it would be clear that a this function doesn't return anything useful.

I'll also note that rjbs didn't say what the subroutine's documentation says. Maybe it reads "Prepares a report and saves it in $file. Doesn't return a damn thing."

Euhm. How are you going to ban implicit returns without requiring return statements?

What I meant was having a standard that if the function returns a useable value, there should be an explicit return statement. If not, then it's OK to leave it out. This way there are fewer returns cluttering up your code, and the syntax is similar to languages like C and Java that have void functions.

The reason that requiring an explicit return is a good idea is that it prevents people from relying on accidental return values. Say I have a method "optimize." It exists only to alter the object, but it happens to end with:

Sure, he shouldn't do that, but preventing other people from making simple mistakes is part of the job of a good programmer. If you don't document the accidentally useful return value, someone will use it. If you don't document the useless return value (say, false) it isn't going to be used.

It means, too, that if you leave it useless and undocumented, later you can make it useful and documented. If it was useful and undocumented to begin with, people's code will break when you change it -- even if you document it.

Sure, people shouldn't used undocumented features, but most people don't think of the RV of a routine as a secret.

Of course, you could always put, in each void-ish routine's docs, "Do not rely on the return value," but it's easier to have it return nothing useful.