This is probably not the right place for this comment, but I just scanned the policies of the perlcritic and I have to say I do violently disagree with quite a few.

• ProhibitLvalueSubstr? Well, maybe.
• ProhibitSleepViaSelect? Agreed.
• ProhibitStringyEval? The summary is incorrect, but yeah, string eval is to be used with care.
• ProhibitUniversalCan? Well well well ... the $foo->can(...) is easier to read, but you may have to check first that the foo is actually a blessed refererence. Otherwise instead of a false value you get an exception/error.
• ProhibitUniversalIsa? Same thing.
• RequireBlockGrep? Why???
• RequireBlockMap? Double why???
• RequireGlobFunction? Why not $FH->readline() and $res = regexp_replace( '\d+', 'number', 'g')? What about Assign( $x, Plus( 5, Times( $y, 7)))?
• RequireSimpleSortBlock? Yeah, anything more complex is too hard for the reader. Use the scalar comma instead of the semicolon if you need to do a bit more.
• ProhibitExplicitISA? If you insist ...
• ProhibitOneArgBless? Agreed.
• ProhibitHardTabs? Hey, it's my business what do I use to format my code, as long as I'm consistent. Why would I type (or have my editor generate) four (or whatever's your favourite number) spaces when one tab is enough? You don't mix'em!
• ProhibitParensWithBuiltins? Severity 1? OK. I don't think it matters at all but ...
• ProhibitQuotedWordLists? Yeah and confuse newbies and people that have Perl as their tenth and seldom used language just to save a few characters. Why would anyone care to check for this?
• RequireTrailingCommas? OK, it's better to put it there in case you need to move things around, but ... is this worth testing?
• ProhibitCStyleForLoops? I think you meant "use for my $i (1..20) instead of for($i=0; $i<=20; $i++)" right? Am I supposed to use for my $i (map {$_ * 2} (0..10)) instead of for($i=0; $i<=20; $i+=2) as well? I'd agree that this for(my $i=0; $i <= $#arr; $i++) is a red flag and most likely a for my $item (@arr) would be preferable, but to outright "ban" the C style for loop?
• ProhibitCascadingIfElse? Well, sometimes there's no other way dude!
• ProhibitPostfixControls? Why don't we program in VBScript then? It's simple and totally dumbed down. You might like it. Postfix controls, be it "if", "for" or "while" often lead to code that more clearly captures the thought flow of the author, that is easier to read and stresses the important part of the sentence ... I mean ... statement.
• ProhibitUnlessBlocks? Kinda agreed.
• ProhibitUnreachableCode? Well, agreed. Unreachable code is quite common while debugging, but in production code it's a red flag. You either forgot to delete something or remove some debug stuff or simply misunderstood something
• ProhibitUntilBlocks? Perl has until()? I've never used it or seen it
• RequirePodAtEnd? Other people say, put the documentation next to the things being documented. I think they are right. Doesn't seem important to me.
• RequirePodSections? Agreed.
• ProhibitBacktickOperators? Why use something simple if you can use for example IPC::Open3, right?
• ProhibitBarewordFileHandles? Agreed.
• ProhibitOneArgSelect? OK
• ProhibitReadlineInForLoop? Agreed
• ProhibitTwoArgOpen? Agreed. Though q{<} looks horrible to me. See bellow.
• RequireBracedFileHandleWithPrint? Show me someone who does this!
• ProhibitFormats? I never tried them. They probably do have their place though. And I don't think the people that do use them need their hands held, they tend to know what they are doing.
• ProhibitTies? Ban the magic! She's a witch, she's a witch, burn her! (just came from Silent Hill) I don't see a reason to ban something that lets me use all the syntactic sugar Perl has for arrays and hashes with objects. If it helps me to write less and easier to read code. Would anyone want to have to rewrite the whole script once you find your hash doesn't fit in the memory?
• RequireRcsKeywords? Some people may want that, maybe.
• ProhibitAutomaticExportation? OK
• ProhibitEvilModules? OK
• ProhibitMultiplePackages? I wonder what proportion of well know and widely used CPAN modules would fail this. If I need a tiny little internal helper class I don't see why would I want to put it into a separate file.
• RequireBarewordIncludes? OK
• RequireEndWithOne? We can't have some fun, can we?
• RequireExplicitPackage? Agreed
• RequireVersionVar? Agreed
• ProhibitAmbiguousNames? $thisIsTheLastValueIveSeenInThisFourLinesLongLoopUsingTheDefaultVariable
• ProhibitMixedCaseSubs? I think there should be a ProhibitUnderscoredSubs available as well, I don't think we can all agree on this
• ProhibitMixedCaseVars? Same as above
• ProhibitDoubleSigils? I'd only prohibit double sigils if there is a [ or { following the variable name, I would not want to have to write push @{$arr_ref}, $foo. OTOH, @$foo[1,2,5] would left me wondering whether it really means what I think it does for a moment.
• RequireExtendedFormatting? I find the /x-ed regexps harder to read most of the time. Yeah if it's something long and complex then /x migth help, but ...
• RequireLineBoundaryMatching? Huh?
• ProhibitAmpersandSigils? Fine with me
• ProhibitBuiltinHomonyms? Agreed completely
• ProhibitExcessComplexity? OK
• ProhibitExplicitReturnUndef? Sure
• ProhibitSubroutinePrototypes? Agreed. most of the time
• ProtectPrivateSubs? OK
• RequireFinalReturn? Well ... if the subroutine is longer than one or two lines.
• ProhibitNoStrict and ProhibitNoWarnings? You might want to warn about this, but I'd think that if you do use strict/warnings and just turn them off for a moment then you probably know what you are doing.
• RequireUseStrict and RequireUseWarnings? Sure
• ProhibitConstantPragma? I know how to handle my constants thank you very much. Readonly scalars are not inlined so the optimizer has no way to make use of the fact they are constant. Might mean a lot for thing like print STDERR "..." if DEBUG; in a tight loop.
• ProhibitEmptyQuotes? What? Beg your pardon?? Why the heck would I want to use q{} in place of ''??? And severity 2????
• ProhibitEscapedCharacters? Well... does anyone know where do I find the table of those \N{whatever} things??? OTOH everyone knows what \x0D\x0A means. Besides I bet quite often there either is no name or you really want this specific byte, not whatever your OS thinks is \N{foo} at the moment.
• ProhibitInterpolationOfLiterals? OK. Though the only speed difference is during compilation AFAICT.
• ProhibitLeadingZeros? OK
• ProhibitMixedBooleanOperators? Agreed. though I wonder whether the policy really prohibits just the mixed use.
• ProhibitNoisyQuotes? What? Beg your pardon?? Use q{} to make them even noisier? q{,} instead of ','??? I mean, if I need to include quotes in the string, I'm all for switching to q{} or qq{} or even heredocs, but requiring the use of q{} for anything that's not purely alphanumeric?? What's noisy about comma?
• ProhibitVersionStrings? OK
• RequireInterpolationOfMetachars? I don't think I understand this one.
• RequireNumberSeparators? Don't care.
• RequireQuotedHeredocTerminator? Agreed
• RequireUpperCaseHeredocTerminator? Why would I want to restrict the terminator if I need to be sure it will not be present in the literal?
• ProhibitConditionalDeclarations? Right, this is not well defined so let's not do this.
• ProhibitLocalVars? Agreed
• ProhibitMatchVars? Agreed
• ProhibitPackageVars? Sometimes package vars are the right thing
• ProhibitPunctuationVars? And send most people searching the source code where did the $EVAL_ERROR variable came from. What's the "ENGLISH" for $!, $/ and $; ? Did you know what it was without consulting the docs?
• ProtectPrivateVars? OK
• RequireInitializationForLocalVars? my $data = do {local $/ = undef; <$FH>}? Well, if you insist.

It looks like I do not feel so strong about most as I thought at first, looks like the first several I looked at were the (IMHO) craziest, but anyway ... there are some rules I would rather people not follow. :-(