Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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."
      • Perhaps a better standard would be to ban them instead of requiring unnecessary return statements.

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

        In any case, my point was that if an explicit return would make the code self-documenting.

        • 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:

              ...
              $self->finalize;
            }
            ...and $self->finalize returns $self. Now optimize returns self. Someone, via whatever means (possibly debugging, possibly reading the source, etc), notices this and writes:

              print $object->optimize->name, " optimized!";
            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.
            --
            rjbs