Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

perl::critic::policy::subroutines::requirefinalreturn(3) [centos man page]

Perl::Critic::Policy::Subroutines::RequireFinalReturn(3)User Contributed Perl DocumentatioPerl::Critic::Policy::Subroutines::RequireFinalReturn(3)

NAME
Perl::Critic::Policy::Subroutines::RequireFinalReturn - End every path through a subroutine with an explicit "return" statement. AFFILIATION
This Policy is part of the core Perl::Critic distribution. DESCRIPTION
Require all subroutines to terminate explicitly with one of the following: "return", "carp", "croak", "die", "exec", "exit", "goto", or "throw". Subroutines without explicit return statements at their ends can be confusing. It can be challenging to deduce what the return value will be. Furthermore, if the programmer did not mean for there to be a significant return value, and omits a return statement, some of the subroutine's inner data can leak to the outside. Consider this case: package Password; # every time the user guesses the password wrong, its value # is rotated by one character my $password; sub set_password { $password = shift; } sub check_password { my $guess = shift; if ($guess eq $password) { unlock_secrets(); } else { $password = (substr $password, 1).(substr $password, 0, 1); } } 1; In this case, the last statement in check_password() is the assignment. The result of that assignment is the implicit return value, so a wrong guess returns the right password! Adding a "return;" at the end of that subroutine solves the problem. The only exception allowed is an empty subroutine. Be careful when fixing problems identified by this Policy; don't blindly put a "return;" statement at the end of every subroutine. CONFIGURATION
If you've created your own terminal functions that behave like "die" or "exit", then you can configure Perl::Critic to recognize those functions as well. Just put something like this in your .perlcriticrc: [Subroutines::RequireFinalReturn] terminal_funcs = quit abort bailout BUGS
We do not look for returns inside ternary operators. That construction is too complicated to analyze right now. Besides, a better form is the return outside of the ternary like this: "return foo ? 1 : bar ? 2 : 3" AUTHOR
Chris Dolan <cdolan@cpan.org> COPYRIGHT
Copyright (c) 2005-2011 Chris Dolan. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. The full text of this license can be found in the LICENSE file included with this module. perl v5.16.3 2014-06-09 Perl::Critic::Policy::Subroutines::RequireFinalReturn(3)

Check Out this Related Man Page

Perl::Critic::Policy::Subroutines::ProtectPrivateSubs(3pUser Contributed Perl DocumentatPerl::Critic::Policy::Subroutines::ProtectPrivateSubs(3pm)

NAME
Perl::Critic::Policy::Subroutines::ProtectPrivateSubs - Prevent access to private subs in other packages. AFFILIATION
This Policy is part of the core Perl::Critic distribution. DESCRIPTION
By convention Perl authors (like authors in many other languages) indicate private methods and variables by inserting a leading underscore before the identifier. This policy catches attempts to access private variables from outside the package itself. The subroutines in the POSIX package which begin with an underscore (e.g. "POSIX::_POSIX_ARG_MAX") are not flagged as errors by this policy. CONFIGURATION
You can define what a private subroutine name looks like by specifying a regular expression for the "private_name_regex" option in your .perlcriticrc: [Subroutines::ProtectPrivateSubs] private_name_regex = _(?!_)w+ The above example is a way of saying that subroutines that start with a double underscore are not considered to be private. (Perl::Critic, in its implementation, uses leading double underscores to indicate a distribution-private subroutine-- one that is allowed to be invoked by other Perl::Critic modules, but not by anything outside of Perl::Critic.) You can configure additional subroutines to accept by specifying them in a space-delimited list to the "allow" option: [Subroutines::ProtectPrivateSubs] allow = FOO::_bar FOO::_baz These are added to the default list of exemptions from this policy. Allowing a subroutine also allows the corresponding method call. So "FOO::_bar" in the above example allows both "FOO::_bar()" and "FOO->_bar()". HISTORY
This policy is inspired by a similar test in B::Lint. BUGS
Doesn't forbid "$pkg->_foo()" because it can't tell the difference between that and "$self->_foo()". SEE ALSO
Perl::Critic::Policy::Variables::ProtectPrivateVars AUTHOR
Chris Dolan <cdolan@cpan.org> COPYRIGHT
Copyright (c) 2006-2011 Chris Dolan. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. The full text of this license can be found in the LICENSE file included with this module. perl v5.14.2 2012-06-07 Perl::Critic::Policy::Subroutines::ProtectPrivateSubs(3pm)
Man Page