All the Perl that's Practical to Extract and Report

Navigation

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

As wonderful as warnings are for debugging, I refuse to explicitly defeat the warning system in an effort to create an artifical silence. The "used only once" bit has got to be one of the most annoying, and I can't believe how much code I see with some pointless "second use" of a var followed by a "# keep -w happy" comment of some kind.

I've barely dipped my toes into perl 5.6 so I'm not sure how much better things have gotten, but the "used only once" test is a good indicator as far as I'm concerned. I

I dont agree for two different reasons:
1. probably many old scripts that did not use strict would break;
2.(most important reason) I believe Perl is a language for free people - it doesnt want you to do things in a unique way. You have objects, but you dont have to use them. You have coding guidelines, but yount have to follow them. You can write pretty obscure and buggy cose if you want to. TIMTOWTDI. This is in my opinion one of the most important philosophical points of the whole thing, and this is on

--"Love, work and knowledge are the well-springs of our life. They should also govern it." - W. Reich

Do all of the support scripts that come with perl support being forced into use strict mode? This change would break a lot of script that would need a 'no strict; no warnings' at the beginning to fix, but in the actual Perl tree, i'd like to see cleanup instead, if it's needed.

I don't think our() will help avoid the "possible typo" warning that much unless someone is accustomed to slinging around globals without using "strict" and "vars" (in which case they deserve what they get). But pity the poor programmer who wants to, say, alias a subroutine name for backwards compatibility via *foo = \&goo; "Used only once! Possible typo! Check your oven!" Bleh.

I originally thought opposite, but then realized that you just made a really good point: Perl's design is to allow the maximum amount of freedom possible with the default 'configuration', and then allow the user to pick and choose what he wants to restrict, and be warned about. Having stricture and warnings on by default would, in this sense, be somewhat inconsistent.

Yes, there are "good reasons" to use a variable once, or at least once in a package space. If you need to, you can do this...
use warnings;
{
no warnings 'once';
print *Another::Package::used_once = sub { 1 };
}

If 80 percent of Perl users thought grep should grep a file for some text, should we change it to do so?

I don't think such numbers matter much. I think right and wrong, when applicable, matter. And I think they are applicable here. I think it is wrong to force me to have to type an extra flag or something to get my hundreds of one-liners and short scripts to compile.

So let's talk about numbers in this manner: you think it is bogus to say old programs would break, that old programs are broken by many

I think warnings are great, but there are a lot of times where I know what I'm doing and I don't want warnings cluttering up the screen or the logfiles. The one that bugs me the most is the "Use of uninitialized value at..." where it really doesn't hurt in some cases to use an uninitialized variable.

As with the 'use strict' pragma as well, it slows your program down a bit, so I usually keep the warnings while developing, but then take them out on production code.

I like the idea of warnings and stricture on by default (I will even take it a step further and say -T could be on by default as well). I would think maybe some options when building Perl like USE_STRICT, WARNINGS, and TAINT which would have Perl use these by default, and then a developer would need to turn them off explicitly (Maybe something in Config.pm would denote if these are on or off).

I think it could be useful, and here is why. As duff said, there are many new programmers which we always tell the