Perl::Critic::Policy::Variables::ProhibitEvilVariables - Ban variables that aren't blessed by your shop.

       This Policy is part of the core Perl::Critic distribution.

       Thomas R. Wyant, III wyantatcpandotorg

       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.

       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.

perl v5.40.0                                       2024-10-28             Perl::Critic::P...itEvilVariables(3pm)

       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.

       Perl::Critic::Policy::Variables::ProhibitEvilVariables - Ban variables that aren't blessed by your shop.

       This policy leans heavily on Perl::Critic::Policy::Modules::ProhibitEvilModules by Jeffrey Ryan
       Thalhammer.

       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__}.