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
