Was this trip really necessary?
Read this thread from back in September.
http:[EMAIL PROTECTED]/msg00167.html
There's also a whole mailing list devoted to this.
http:[EMAIL PROTECTED]/
I've argued why warnings should be on by default (except in one-liners)
and lost. Its all been said, guys.
Even with warnings on, they are all too often ignored. Just today I
got an email from a friend asking "why doesn't this program work"?
The program was throwing a warning, but he'd ignored it. Turns out it
was one of the problems. And he's no newbie.
Taint by default is just right out, I would hope this would be
obvious. Any program which takes, say, a filename from the command
line and uses it to open a file for writing would have to do pointless
detainting. It would become a useless ritual in /(.*)/. Worse, one
would get used to that idiom and put it in places where you're
*really* supposed to be detainting.
strict by default is right out. That's not the sort of language Perl is.
And before you start in on taint more, there are already a few RFCs on
improving it, read them.
I'm the bloody QA chair and I don't even think its a good idea anymore.
The idea of auditing other's code (CPAN for instance) is WAY more
complicated than just "you must use taint, warnings and strict". 750
megs of code from 1000+ authors around the world, there's no way in
hell you can enforce such simplistic and arbitrary standards. See
http:[EMAIL PROTECTED]/msg00148.html for some
ideas.
Now, there are numerous ways to enforce good style on your local
development environment. You can replace perl on your production
machine with something that does "perl -Mstrict -Tw" if you really
want (be prepare to watch lots of modules break internally under
taint). You can run modules and programs with some of the auditing
tools available and in the works (Dunce::Files for one, more on the
way). You can add to your default Makefile.PL a simple scan for "use
strict", etc... You can use a test & review enforcement system such
as Aegis. Set up code standards and enforce them with a scanning
program. Test coverage analysis is being built into Test::Harness,
etc...
You have to do all this anyway, flipping a few command line switches
isn't going to solve fundemental software engineering problems. Yes,
it would be nice if warnings were on by default, but it has too many
caveats. Its also all to easy to be shut off (and don't think that's
not the first switch a newbie will find).
Supply your own discipline, don't make the language do it or you will
be sorry. (Devo moment... "Freedom of choice is what you got, freedom
from choice is what you want") And please avoid the temptation to drag
this point ad nauseum.
Instead of Yet Again arguing back and forth on this, go write me some
code auditing tools.
