Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

perl::critic::policy::variables::prohibitreusednames(3) [centos man page]

Perl::Critic::Policy::Variables::ProhibitReusedNames(3) User Contributed Perl DocumentationPerl::Critic::Policy::Variables::ProhibitReusedNames(3)

NAME
Perl::Critic::Policy::Variables::ProhibitReusedNames - Do not reuse a variable name in a lexical scope AFFILIATION
This Policy is part of the core Perl::Critic distribution. DESCRIPTION
It's really hard on future maintenance programmers if you reuse a variable name in a lexical scope. The programmer is at risk of confusing which variable is which. And, worse, the programmer could accidentally remove the inner declaration, thus silently changing the meaning of the inner code to use the outer variable. my $x = 1; for my $i (0 .. 10) { my $x = $i+1; # not OK, "$x" reused } With "use warnings" in effect, Perl will warn you if you reuse a variable name at the same scope level but not within nested scopes. Like so: % perl -we 'my $x; my $x' "my" variable $x masks earlier declaration in same scope at -e line 1. This policy takes that warning to a stricter level. CAVEATS
Crossing subroutines This policy looks across subroutine boundaries. So, the following may be a false positive for you: sub make_accessor { my ($self, $fieldname) = @_; return sub { my ($self) = @_; # false positive, $self declared as reused return $self->{$fieldname}; } } This is intentional, though, because it catches bugs like this: my $debug_mode = 0; sub set_debug { my $debug_mode = 1; # accidental redeclaration } I've done this myself several times -- it's a strong habit to put that "my" in front of variables at the start of subroutines. Performance The current implementation walks the tree over and over. For a big file, this can be a huge time sink. I'm considering rewriting to search the document just once for variable declarations and cache the tree walking on that single analysis. CONFIGURATION
This policy has a single option, "allow", which is a list of names to never count as duplicates. It defaults to containing $self and $class. You add to this by adding something like this to your .perlcriticrc: [Variables::ProhibitReusedNames] allow = $self $class @blah AUTHOR
Chris Dolan <cdolan@cpan.org> This policy is inspired by <http://use.perl.org/~jdavidb/journal/37548>. Java does not allow you to reuse variable names declared in outer scopes, which I think is a nice feature. COPYRIGHT
Copyright (c) 2008-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::Variables::ProhibitReusedNames(3)

Check Out this Related Man Page

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

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.16.3 2014-06-09 Perl::Critic::Policy::Subroutines::ProtectPrivateSubs(3)
Man Page