New logicLAB Policy for Perl::Critic Policy: ModuleBlacklist

From the MOTIVATION section in the POD of this new policy:

I once read an article which compared programming languages to natural languages. Programming languages in themselves are not large as such, but if you also regard the APIs, data structures and components a computer programmer use on a daily basis, the amount is enormous.

Where I work We try to keep a more simple code base, the complexity is in our business and that is our primary problem area, so it should not be difficult to understand the code used to model this complexity.

So sometimes it is necessary to make a decision on what should be allowed in our code base and what should not. This policy aims to support this coding standard.

This sounds fairly unproblematic and peaceful, but there is a more sinister motivation behind the implementation as well.

After long debugging sessions at the most inconvenient times involving a small set of modules, which causes me too many problems – I decided to write this policy.

Over the cause of time and working in a growing team, we have a constantly growing code base and many takes on how to accomplish things and solving problems. Constantly our code base is breaking and new bugs are introduced and this is all okay and a pretty natural part of software development.

Developers are great!

– They add value
– They add code
– They fix stuff
– They build stuff

But…

– They introduce bugs
– They implement security holes
– They add code
– They break stuff

So sometimes that have to be regulated.

We use peer reviews, not to the extent we should, but we do try and aim try to have this is a part of our SDLC (Software Development Life Cycle). Sometimes we tend to discuss the somethings over and over and perhaps at some point we decide to adjust our coding policy to accommodate the outcome.

My thesis is a that we should use Perl::Critic and Perl::Tidy to enforce our coding standard to the extent possible so peer reviews can focus and can be provide maximum value and we can discuss business, value, security and discover new anti-patterns/patterns, instead of discussing old hat.

So when a certain issue has been observed on more that one occasion, write a policy to enforce a regulation against to address it.

This policy can help you to enforce a regulation when you want to prohibit use of certain modules or even when you want to recommend alternatives.

So if you want to specify a list of blacklisted modules:

[logicLAB::ModuleBlacklist]
modules = Try::Tiny, Contextual::Return, IDNA::Punycode

And if you want to hint at recommendations for use:

[logicLAB::ModuleBlacklist]
modules = Try::Tiny => TryCatch, Contextual::Return, IDNA::Punycode => Net::IDN::Encode

Please note that this is the first shot at the policy, feedback and suggestions most welcome (Github).

Happy regulating,

jonasbn, Copenhagen

Advertisements
New logicLAB Policy for Perl::Critic Policy: ModuleBlacklist

Yet Another New Perl::Critic policy in the pipeline: RequirePackageNamePattern

I have written up a first working version of yet another Perl::Critic policy, also this policy suggestion is highly experimental.

The policy assists in enforcing a package/module/class naming strategy, so if you prefer to have your modules names follow a certain pattern this policy could be of interest to you.

If you do not configure the policy it does not do anything. You can however configure it with as many patterns as you would like:

Patterns could look as follows:

^Acme # if you want all of you modules to start with Acme
Acme # if you want all of your modules to contain the work Acme
Acme$ # if you want all of you modules to end with Acme

For now you can only specify global patterns, but I was considering looking into the ability to specify different patterns for different directories:

Names
lib = <pattern1> || <pattern2>
t = <pattern1> || <pattern3>

And creating more complex patterns would also be great, like:

^Acme.*Test$

or:

^Acme && Test$

In addition the policy has the following configurable parameters:

– debug (for debugging)

– exempt_programs, so scripts etc. are not evaluated, these can however be of interest if you use inline packages

The motivation is to use the policy as a part of a coding standard for use at my work place, but I have developed it in my spare time since I wanted to contribute it to CPAN and as for my other policies I would like too use it on my own open source code base to begin with.

I will pack it up and push it to CPAN in a few days, but you are welcome to check it out on Github, please note that the policy is by no means done and much work remains.

jonasbn, logicLAB

Yet Another New Perl::Critic policy in the pipeline: RequirePackageNamePattern

New Perl::Critic policy in the pipeline: RequireParamsValidate

Inspired by my fellow hackers attending the Nordic Perl Workshop, I took the time to sit down (I was actually attending the Internetdagarna conference in Stockholm) and wrote up a first working version, so for now I consider this policy suggestion highly experimental.

The policy evaluates Perl subroutines for the presence of use of Params::Validate. It currently only evaluates public facing APIs, meaning subroutines prefixed with ‘_’ (private by convention) are ignored. This will be made configurable later.

I have run some basic tests and found one funny thing – the implementation itself does not comply with what the policy enforces and encourages.

The motivation is to use the policy as a part of a coding standard for a larger project on which I am embarking soon, but I would like too use it on my own code base to begin with.

I will pack it up and push it to CPAN within a few days, but you are welcome to check it out on Github.

jonasbn, logicLAB

New Perl::Critic policy in the pipeline: RequireParamsValidate