I know I just blogged about this policy in "Blog post: Static Analysis in Perl - or yet another policy", but as I concluded the post I am pondering trying to get the policy adopted into Perl::Critic core.

I looked at the TODO list and list of known issues and decided that the policy was not ready for a PR to Perl::Critic, since I want it to have all the features I have listed implemented.

Sparked by a sudden inspiration I got the last feature implemented and the result has been uploaded to CPAN as 2.00.

Release 2.00 introduces the ability to configure if you want the evaluation performed by the policy to be strict or liberal (the default).

So you can add a configuration parameter to your Perl::Critic profile and enable strictness.

[RegularExpressions::RequireDefault]
strict = 1

The policy, if enabled, allow for both a and aa by default. If strict however is enabled, a will trigger a violation and aa will not, hence the strictness.

Example:

my $ascii_letters =~ m/[A-Z]*/i;  # not ok
my $ascii_letters =~ m/[A-Z]*/a;  # ok, but not ok with strict enabled
my $ascii_letters =~ m/[A-Z]*/aa; # ok

The policy also evaluates if the pragmas are enabled under the same conditions:

Example:

use re 'a';  # ok, but not ok with strict enabled
use re 'aa'; # ok

The implementation still has an issue with the pragma use in general, since it is difficult to handle the enabling and disabling of pragmas locally in the source code. Perl::Critic works on a external parsing of the source code in question using PPI, meaning not the actual AST as you can see some static analysis tools do, so these things do not come as easily as for these tools, which work more integrated into the actual parsing of the source code.

Anyway I will now continue my evaluation of the possibility of getting the policy adopted by Perl::Critic.