Perl::Critic is a tool that evolved out of the practical (or perhaps impractical depending on who you ask) application of Damian Conway's book, Perl Best Practices. Some authors use Perl::Critic to double-check that they're not doing something in their code that might either be a fairly common mistake, or that might hurt the maintainability of the target code. By invoking perlcritic scriptname, a bunch of warnings related to "Best Practices" concerns for the target script will be printed. An author using this tool might then review each of the warnings he gets, and decide whether it is better to change the code, or let the code stand as-is and possibly squelch the warning.
For example, we're all taught through the popular repitition here that string eval is considered harmful. Perl::Critic reinforces that by throwing a warning if we use string eval in our code. Yet perlmodstyle specifically prescribes the use of string eval to normalize the version numbers of developers releases. Here we have a best practice that is pretty good advice, and Perl documentation that is also pretty good advice, and yet they're at odds with each other. The module author has to decide whether to change his code, change whether or not the warning prints, or just ignore it.
Just ignore it seems like the easiest approach, but six months from now an author might make some changes to his code, run perlcritic, and see a bunch of warnings. Some of those he is supposed to just ignore, but one or two may be new. Which is which? This is why it might be advisable to simply squelch a particular warning; to eliminate noise, making it easier to spot new or un-reviewed warnings.
Another reason to suppress warnings that have been reviewed and found to not be an issue is if the author uses Test::Perl::Critic. One probably wouldn't want his module to fail its test suite because he used the posfix conditional if. But he might want to know about such issues when he builds his distribution. By making Test::Perl::Critic an optional test, active only during release testing, and only if the Test::Perl::Critic module is installed, the author can double check his work automatically while testing his distribution.
Perl::Critic provides several mechanisms for altering what warnings get generated. One is to add your own configuration to Perl::Critic; one that possibly adds new warnings, and squelches others, on a global scale. Another is to pepper your code with the occasional "## no critic (warning_name)" in a way similar to the use of no warnings; pragma. And another way is to place "## no critic (warnings_name)" at the end of a specific line of code, in which case the warning is suppressed just for that line of code.
I don't see the use of Perl::Critic as being such a bad thing. Occasionally it throws up a red flag that upon revew I discover could be a real issue that might have led to a real bug. We write our test suites to help catch potential bugs in our code. That takes time, and yet we consider it worthwhile. Why not spend an extra few minutes reviewing some of Perl::Critic's advice "just in case"? It might happen to notice something that the author isn't looking at in his tests. Just because we don't agree with all of it doesn't mean none of it is worthy of consideration.
So the code you are looking at is code that the author occasionally runs through perlcritic. Hopefully (s)he has reviewed the warning that Perl::Critic generates, and in the case of the one you mentioned, has decided that his use of eval is both safe, and the best approach to solving the problem at hand. While that assessment may still be incorrect, you know that at least he's thought about it enough to go ahead and suppress the warning for that specific line of code.
| 