Perl::Critic::TooMuchCode is a set of policy addons that generally checks for dead code or redundant code.
In version 0.17 we updated the policy ProhibitDuplicateLiteral to include a new config parameter
whitelist to replace the old parameter
whitelist_number. In version 0.18 they are both removed. The replacement for them is the parameter
So now if we really need to write number 42 and "forty two" literally many times, we list them in
[TooMuchCode::ProhibitDuplicateLiteral] allowlist = "forty two" 42
The name "allowlist" was previously suggested by @ferki already and I amended to match existing convention of using "whitelist". Now I decide that such convention should be changed (See PR #28). It's a better naming choice in the sense that it direct and explicit, perhaps until the day the word "allow" lost its current meaning.
The other improvement is to address Issue 18 (thanks to @oalders again.), in which assignment of imported symbols to
@EXPORT_OK as correctly counted as using those symbol by the policy ProhibitUnusedImport.
There have not counted because it is also a correct thing to do. Considering we have three symbols in place:
@baz, and an assignment like this:
my @stuff = qw(foo $bar @baz);
Although those symbols appears in the statement literally, evaluating that statement does not depends on the evaluation of those symbols because they are all quoted inside of
@stuff is evaluated to 3 strings:
'@baz', which has nothing to do with
foo (bareword, perhaps a subroutine name),
$bar, and '@baz'.
However, if the LHS array variable is either
@EXPORT_OK, the assignment has different meaning:
our @EXPORT = qw(foo $bar @baz); our @EXPORT_OK = qw(@baz);
@EXPORT itself is still assigned with just 3 strings, but eventually when the current module is imported (
require-ed) by a foreign piece of code, those 3 strings refer some content in the symbol table and they might be used remotely.
foo is really used remotely is probably unknown-able. It should be sufficient to just consider the case of assignments involving
I'm guessing that there are probably more special cases yet to be discovered regarding those special variables in perlvar, or however famous module X defined its own sub-language for us to cope with.
Originally posted at gugod's blog -- CPAN Release of TooMuchCode 0.18