DEV Community

Kang-min Liu
Kang-min Liu

Posted on

3 1

CPAN Release of TooMuchCode 0.18

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
Enter fullscreen mode Exit fullscreen mode

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);
Enter fullscreen mode Exit fullscreen mode

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);
Enter fullscreen mode Exit fullscreen mode

@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

Image of Docusign

🛠️ Bring your solution into Docusign. Reach over 1.6M customers.

Docusign is now extensible. Overcome challenges with disconnected products and inaccessible data by bringing your solutions into Docusign and publishing to 1.6M customers in the App Center.

Learn more

Top comments (0)

A Workflow Copilot. Tailored to You.

Pieces.app image

Our desktop app, with its intelligent copilot, streamlines coding by generating snippets, extracting code from screenshots, and accelerating problem-solving.

Read the docs

👋 Kindness is contagious

Explore a sea of insights with this enlightening post, highly esteemed within the nurturing DEV Community. Coders of all stripes are invited to participate and contribute to our shared knowledge.

Expressing gratitude with a simple "thank you" can make a big impact. Leave your thanks in the comments!

On DEV, exchanging ideas smooths our way and strengthens our community bonds. Found this useful? A quick note of thanks to the author can mean a lot.

Okay