Perl::Critic::TooMuchCode is a set of policy addons that generally checks for dead code or redundant code.

It's just about a week after the release of 0.17 and after asynchronously exchanged some thoughts with @oalders and @ferki (Issue #25), I decide to make a follow-up release shortly.

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 allowlist.

So now if we really need to write number 42 and "forty two" literally many times, we list them in .perlcriticrc:

[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 or @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: foo, $bar, and @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 qw(). @stuff is evaluated to 3 strings: 'foo', '$bar', and '@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 or @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 (use-ed or require-ed) by a foreign piece of code, those 3 strings refer some content in the symbol table and they might be used remotely.

Well, whether foo is really used remotely is probably unknown-able. It should be sufficient to just consider the case of assignments involving @EXPORT and @EXPORT_OK.

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