Re: pgsql: Perl scripts: eliminate "Useless interpolation" warnings

On Sun, Sep 15, 2024 at 02:30:47PM -0400, Andrew Dunstan wrote:

On 2024-09-15 Su 10:56 AM, Bruce Momjian wrote:
    Perl scripts:  eliminate "Useless interpolation" warnings
    Eliminate warnings of Perl Critic from src/tools.
    Backpatch-through: master



I don't understand this commit. The buildfarm members crake and koel regularly
run the perl critic checks and have not complained. See for example from before
this change: <https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=
koel&dt=2024-09-15%2003%3A34%3A02&stg=perl-check>

The change doesn't seem to have had any discussion either. This particular
warning is surely a very low level (i.e. fairly unimportant) one, of the type
we normally ignore. If some version of perlcritic has raised it to severity 5
then the correct action IMNSHO would be to add an exception for it to the
perlcriticrc, like we do for ProhibitLeadingZeros. If not, then perhaps you can
explain how you got the warnings.

So, the warning is about the use of double-quotes when single-quotes
will work just fine.  I wrote a new script and changed it to single
quotes, so for consistency, I looked at other Perl scripts that might
have the issue.  The message I got was:
   /root/add_commit_links.pl: Useless interpolation of literal string at line 51 near 'my $tmpfile = $file . ".tmp";'.  (Severity: 1)

My $HOME/.perlcritic has:
	severity = 1

and that is why I saw it.  Is it a bad change?

I understand perfectly what the warning is about.

But the project's perlcritic policy is expressed at src/tools/perlcheck/perlcriticrc. It's basically severity 5 plus some additions and one exception. We shouldn't be imposing our personal perlcritic policies on the project.

The change isn't bad in itself, but there shouldn't be any expectation that we will keep to this policy, as it's not required by project policy.

There is a huge mass of perlcritic issues in our perl code at severity 1 (over 13000 by my count). If we're going to clean them up (which I would oppose) we should do it in a systematic way. It's hard to see why this one is special.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com