G'day chromatic / QA,
chromatic wrote:
I also hate to get bug reports saying "You should add this line of code even
if it does nothing useful to all of your modules, because it's not there!"
Unfortunately while the code may do nothing useful to *your* modules per se,
it's extremely useful should any be using your modules in a program that
uses taint mode and wants to be careful about their data. It's rather
awkward that Perl has ended up with the same code that commonly means "parse
this data" to implicitly mean "this data is safe".
There's definitely a place for something that changes the default behaviour
of perl to *not* automatically untaint when using regexps, but I haven't
even looked into how difficult such a piece of code would be.
I'm very much not happy to get bug reports and test failures and big red bars
against my distributions because an automated heuristic which applies only to
some cases decided that it knows better about how to write code than I do.
One could argue this is the case for all the CPANTS tests. Why should your
code use strict, or warnings, or Test::Pod::Coverage, or have its tests in
t/ ? These are all just automated heuristics telling me how to write my code.
However I certainly take your point that we can go overboard with CPANTS
heuristics.
Is there someplace this should be going besides from CPANTS?
It's definitely a common mistake that module authors can easily fix.
Perl::Critic?
Perl::Critic is an excellent suggestion, if nothing else because I'd love to
apply the critic tests to my own code, even if they're not inflicted on the
rest of the world. ;)
Thanks for the excellent feedback,
Paul
--
Paul Fenwick <[EMAIL PROTECTED]> | http://perltraining.com.au/
Director of Training | Ph: +61 3 9354 6001
Perl Training Australia | Fax: +61 3 9354 2681
