Perl::Critic::Policy::Variables::ProhibitEvilVariables(3pm) | User Contributed Perl Documentation | Perl::Critic::Policy::Variables::ProhibitEvilVariables(3pm) |
Perl::Critic::Policy::Variables::ProhibitEvilVariables - Ban variables that aren't blessed by your shop.
This Policy is part of the core Perl::Critic distribution.
Use this policy if you wish to prohibit the use of specific variables. These may be global variables warned against in "perlvar", or just variables whose names you do not like.
The set of prohibited variables is configurable via the "variables" and "variables_file" options.
The value of "variables" should be a string of space-delimited, fully qualified variable names and/or regular expressions. An example of prohibiting two specific variables in a .perlcriticrc file:
[Variables::ProhibitEvilVariables] variables = $[ $^S $SIG{__DIE__}
If you prohibit an array or hash (e.g. @INC), use of elements of the array or hash will be prohibited as well. If you specify a subscripted variable (e.g. $SIG{__DIE__}), only the literal subscript specified will be detected. The above <.perlcritic> file, for example, will cause "perlcritic (1)" to detect "$SIG{__DIE__} = \&foo", but not
my $foo = '__DIE__'; $SIG{$foo} = \&foo;
Regular expressions are identified by values beginning and ending with slashes. Any variable with a name that matches "m/pattern/sm" will be forbidden. For example:
[Variables::ProhibitEvilVariables] variables = /acme/
would cause all variables that match "m/acme/" to be forbidden. If you want a case-blind check, you can use (?i: ... ). For example
[Variables::ProhibitEvilVariables] variables = /(?i:acme)/
forbids variables that match "m/acme/smi".
In addition, you can override the default message ("Prohibited variable "variable" used") with your own, in order to give suggestions for alternative action. To do so, put your message in curly braces after the variable name or regular expression. Like this:
[Variables::ProhibitEvilVariables] variables = $[ {Found use of $[. Program to base index 0 instead}
If your message contains curly braces, you can enclose it in parentheses, angle brackets, or square brackets instead.
Similarly, the "variables_file" option gives the name of a file containing specifications for prohibited variables. Only one variable specification is allowed per line and comments start with an octothorp and run to end of line; no curly braces are necessary for delimiting messages:
$[ # Prohibit the "$[" variable and use the default message. # Prohibit the "$^S" variable and give a replacement message. $^S Having to think about $^S in exception handlers is just wrong # Use a regular expression. /acme/ No coyotes allowed.
By default, there are no prohibited variables, although I can think of a few that should be. See "perldoc perlvar" for a few suggestions.
Variables of the form "${^foo}" are not recognized by PPI as of version 1.206. When PPI recognizes these, this policy will Just Work for them too.
Only direct references to prohibited variables and literal subscripts will be recognized. For example, if you prohibit $[, the first line in
my $foo = \$[; $$foo = 1;
will be flagged as a violation, but not the second, even though the second, in fact, assigns to $[. Similarly, if you prohibit $SIG{__DIE__}, this policy will not recognize
my $foo = '__DIE__'; $SIG{$foo} = sub {warn 'I cannot die!'};
as an assignment to $SIG{__DIE__}.
This policy leans heavily on Perl::Critic::Policy::Modules::ProhibitEvilModules by Jeffrey Ryan Thalhammer.
Thomas R. Wyant, III wyant at cpan dot org
Copyright (c) 2009-2011 Thomas R. Wyant, III
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.
2018-07-27 | perl v5.26.2 |