CPAN Release of TooMuchCode 0.18
Tags: perl, cpan
Published: 2021-09-29 00:32:55

---
title: CPAN Release of TooMuchCode 0.18
published: true
description: 
tags: perl, cpan
//cover_image: https://direct_url_to_image.jpg
---

[Perl::Critic::TooMuchCode][toomuchcode-cpan] 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][toomuchcode-release-0.17] and after asynchronously exchanged some thoughts with [@oalders][] and [@ferki][] ([Issue #25][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][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][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][perldoc-perlvar], or however famous module X defined its own sub-language for us to cope with.

[toomuchcode-cpan]: https://metacpan.org/dist/Perl-Critic-TooMuchCode
[toomuchcode-release-0.17]: https://gugod.org/2021/09/cpan-release-of-toomuchcode-0.17/
[@ferki]: https://github.com/ferki
[@oalders]: https://github.com/oalders
[issue-25]: https://github.com/gugod/Perl-Critic-TooMuchCode/issues/25
[issue-18]: https://github.com/gugod/Perl-Critic-TooMuchCode/issues/19
[pr-28]: https://github.com/gugod/Perl-Critic-TooMuchCode/pull/28
[perldoc-perlvar]: https://perldoc.pl/perlvar

----
Originally posted at [gugod's blog -- CPAN Release of TooMuchCode 0.18](https://gugod.org/2021/09/cpan-release-of-toomuchcode-0.18/)