use Perl

• In all fairness (Score:1)

  by Aristotle (5147) <pagaltzis@gmx.de> on 2007.10.21 22:07 (#58501) Homepage Journal

  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.

  Reply to This

  • Re: (Score:1)

    by waltman (335)

    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."
    
    • Re: (Score:1)

      by Aristotle (5147)

      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.
      • Re: (Score:1)

        by waltman (335)

        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.
        • Re: (Score:1)

          by rjbs (4671)

          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, h

          --
          rjbs
    • Re: (Score:2)

      by jonasbn (1153)

      The good thing about Perl::Critic, is that it make you think about your code, so you do not just put or leave out statements by habit.
      
      I have just finished a project for a client, I have disabled 8 policies and have documented as to why I have done so in the POD.
      
      So disable the policy and document it

      [-Subroutines::RequireFinalReturn]
      • Re: (Score:1)

        by rjbs (4671)

        Absolutely! I love Perl::Critic, and have written my own policies to remind me to think about stuff. I suggest Perl::Critic readily -- as a diagnostic tool, not as a master.

        --
        rjbs