Re: cleaning perl code - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: cleaning perl code
Date
Msg-id bac7198f-0b2a-8e93-72b7-8b338636aa1f@2ndQuadrant.com
Whole thread Raw
In response to Re: cleaning perl code  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Responses Re: cleaning perl code  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On 4/13/20 12:47 PM, Andrew Dunstan wrote:
>
> OK, I've committed all that stuff. I think that takes care of the
> non-controversial part of what I proposed :-)
>
>

OK, it seems there is a majority of people commenting in this thread in
favor of not doing more except to reverse the policy of requiring
subroutine returns. I'll do that shortly. In the spirit of David
Steele's contribution, here is a snippet that when added to the
perlcriticrc would allow us to pass at the "brutal" setting (severity
1). But I'm not proposing to add this, it's just here so anyone
interested can see what's involved.

One of the things that's a bit sad is that perlcritic doesn't generally
let you apply policies to a given set of files or files matching some
pattern. It would be nice, for instance, to be able to apply some
additional standards to strategic library files like PostgresNode.pm,
TestLib.pm and Catalog.pm. There are good reasons as suggested upthread
to apply higher standards to library files than to, say, a TAP test
script. The only easy way I can see to do that would be to have two
different perlcriticrc files and adjust pgperlcritic to make two runs.
If people think that's worth it I'll put a little work into it. If not,
I'll just leave things here.


cheers


andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Poll: are people okay with function/operator table redesign?
Next
From: Tom Lane
Date:
Subject: Re: Poll: are people okay with function/operator table redesign?