Re: cleaning perl code
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Noah Misch <noah@leadboat.com>, Alvaro Herrera <alvherre@2ndquadrant.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-04-16T13:53:46Z
Lists: pgsql-hackers
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. 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 :-( regards, tom lane
Commits
-
Stop requiring an explicit return from perl subroutines
- 0516f94d18c5 13.0 landed
-
Use perl's $/ more idiomatically
- 8f00d84afc0d 13.0 landed
-
Use perl warnings pragma consistently
- 7be5d8df1f74 13.0 landed