use Perl

• Perl::Critic (Score:1)

  by ChrisDolan (2855)

  Perl::Critic [cpan.org] can help here. There is a plugin called Perl::Critic::Policy::Subroutines:RequireFinalReturn that checks your code and ensures that every subroutine ends with an explicit return (or die, goto, croak or exit).
  
• But I like it (Score:1)

  by Aristotle (5147)

  I get a lot of milage out of implicit return – I write many functions that consist of a single expression (disregarding parameter parsing), which read much nicer that way.

  Maybe precisely because I use it so purposefully, I am always keenly aware that subs always return something, and so when writing subs that aren’t supposed to, I usually put a bare return in there.
  • Re: (Score:2)

    by Matts (1087)

    I do this too, as can be seen in my code on CPAN. I just would like a strict mode to turn it off.
• Default behavior (Score:1)

  by sigzero (5768)

  Aren't those Perl rules? I know that last statement is the return by default is covered in "Learning Perl", so I guess I always have that in my head. The IF statement doesn't bother me as I look at those as blocks.
  • Re: (Score:2)

    by Matts (1087)

    As I said, it was partly due to the dumb API, but often times the last statement is hidden somewhere in an if block, or while block or something. I think I'd personally rather have an explicit return, via use strict 'return';
    • Re: (Score:1)

      by sigzero (5768)

      I think I'd personally rather have an explicit return, via use strict 'return';

      I get what you are saying now.
• It's not the subroutine, it's the block. (Score:1)

  by Abigail (26)

  It's the fact that return value of blocks is the last expression evaluated. And the body of a subroutine is a block.

  The fact that blocks return the last expression evaluated is what makes writing concise maps and greps.

  Also note that whether a subroutine returns something or not is not determined by a return, or a last expression. Like anything else, it's determined by context. A subroutine will return nothing, if, and only if, it's called in void context. Otherwise, it will return something, even if it
  • Re: (Score:2)

    by Matts (1087)

    It's an OO API, so you subclass process_line to process a line of data. But I forgot that (somewhere in another file/class) that if process_line returns a scalar it gets sent to the client. It's hard to see that sort of thing in OO virtual APIs sometimes, but as everyone has rightly pointed out - it was programmer error.
    
    Doesn't mean I think "use strict 'return'" is any less of a good idea though.
  • Re: (Score:2)

    by Dom2 (2981)

    I've been bitten by this in mod_perl handlers. I forgot to return OK, and the final statement was returning undef. That triggered a "Use of uninitialised value" message in the error log... but it had no line number info. That took me months to track down. I've always been very explicit about using return since then.

    -Dom