Re^2: Perl::Critic policy for common Log::Log4perl mistake

Perl::Critic is a static code analyzer and can of course, by definition, not know the runtime length of arrays.

The intention is to create Perl::Critic policy to help track down all logging calls, and then based on the output, help identify which ones are likely to have a negative impact on performance.

--
No matter how great and destructive your problems may seem now, remember, you've probably only seen the tip of them. [1]

Comment on Re^2: Perl::Critic policy for common Log::Log4perl mistake

Replies are listed 'Best First'.
Re^3: Perl::Critic policy for common Log::Log4perl mistake by jethro (Monsignor) on Nov 08, 2011 at 18:21 UTC
I first wanted to reply that this would be nonsense because nobody puts big arrays into error logs (and I still stand by that). A perl_critic rule that produces 99% false positives is not a good perl_critic rule. But then it occured to me that debug-logs might have such calls more frequently. So you got a point, but only in so far as logging level 'debug' is concerned. You might flag all calls to debug that don't have such a if-clause and you actually would have a somewhat sensible rule IMO.	[reply]

Replies are listed 'Best First'.

Re^3: Perl::Critic policy for common Log::Log4perl mistake
by jethro (Monsignor) on Nov 08, 2011 at 18:21 UTC

I first wanted to reply that this would be nonsense because nobody puts big arrays into error logs (and I still stand by that). A perl_critic rule that produces 99% false positives is not a good perl_critic rule. But then it occured to me that debug-logs might have such calls more frequently.

So you got a point, but only in so far as logging level 'debug' is concerned. You might flag all calls to debug that don't have such a if-clause and you actually would have a somewhat sensible rule IMO.

[reply]