Re: cleaning perl code

On Thu, Apr 16, 2020 at 09:53:46AM -0400, Tom Lane wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> > On 4/15/20 11:01 PM, Noah Misch wrote:
> >> It would be an unpleasant surprise to cause a perlcritic buildfarm failure by
> >> moving a function, verbatim, from a non-strategic file to a strategic file.
> >> Having two Perl style regimes in one tree is itself a liability.
> 
> > Honestly, I think you're reaching here.
> 
> I think that argument is wrong, actually.  Moving a function from a single
> use-case into a library (with, clearly, the intention for it to have more
> use-cases) is precisely the time when any weaknesses in its original
> implementation might be exposed.  So extra scrutiny seems well warranted.

Moving a function to a library does call for various scrutiny.  I don't think
it calls for replacing "no warnings;" with "no warnings; ## no critic", but
that observation is subordinate to your other point:

> Whether the "extra scrutiny" involved in perlcritic's higher levels
> is actually worth anything is a different debate, though, and so far
> it's not looking like it's worth much :-(

Yeah, this is the central point.  Many proposed style conformance changes are
(a) double-entry bookkeeping to emphasize the author's sincerity and (b) regex
performance optimization.  Those are not better for libraries than for
non-libraries, and I think they decrease code quality.

Even if such policies were better for libraries, the proposed patch applies
them to .pm files with narrow audiences.  If DBD::Pg were in this tree, that
would be a different conversation.