The same question is currently being discussed: Stray Variables.

merlyn's reply addresses the lexical variable issue.

Casting my mind back a decade or so to Perl4, I do recall having to write code like this to stop the warning messages:

$x || $y || $z || 1;
[download]

What you say about my variables appears to be right on the mark. Here's some tests:

[ ~/tmp ] $ perl -we 'use strict; my $x'
[ ~/tmp ] $ perl -we 'my $x'
[ ~/tmp ] $ perl -we '$x'
Useless use of a variable in void context at -e line 1.
Name "main::x" used only once: possible typo at -e line 1.
[ ~/tmp ] $ perl -we 'no warnings qw(once); $x'
[ ~/tmp ] $
[download]

I would tentatively suggest that the reason stems from the fact that lexically scoped variables are stored in the scratchpad while dynamically scoped variables are stored in the symbol table. Presumably the used only once test is only performed on the symbol table.

Another monk, more familiar with Perl's internals, may be able to provide the reason for this. Anyone?

I'm no internals wizard, but I think you're right on the mark.

But more importantly, this is the correct behavior. The purpose of the warning is (presumably) a second line of defense behind strict, for detecting a mispelled variable names. It's purpose probably isn't to warn you that you didn't use it enough, but rather, that not using an undeclared variable means you may (probably do) have a typo.

In the case of a my declared variable, You'll actually still get the warning if you typo it OTHER THAN in the my call. But if you're using my... shouldn't you also be using strict? I am curious as to the thought process that would lead to using only one of the two.

Examples:

perl -we 'my $foo; $fooo = 42'
Name "main::fooo" used only once: possible typo at -e line 1.
[download]

Typo was still detected.

perl -we 'my $fooo; $foo = 42'
Name "main::foo" used only once: possible typo at -e line 1.
[download]

Typo still detected.

perl -we 'my $fooo;'
[download]

No warning. If it is a typo is questionable. It is like a program with no output; if it DOES anything is a matter for some philosophers. But it doesn't matter. Declaring an extra my var doesn't hurt anything. And if you group all your my calls together like my( $foo, $bar, $baz, ) then it doesn't even waste much time. On many systems, I doubt the difference would be measurable.

And so even in all the examples given prior, the correct behavior of identifying harmful typos is always taken.

Personally, I think it's terrible to write code without strict, when it's code that is important enough, or will last long enough, or is intricate enough, that warnings are needed or used. I would only recommend forgoing use strict on once-off one-liners (ie, system administration and playing around).


--
Snazzy tagline here

I agree with your sentiments on strict.

I often test things like regexes from the commandline before adding to application code. I always include warnings and strictures in these tests:

perl -we 'use strict; ...'
[download]

Whenever I fiddle with these in a script or module, I tend to go into blatently-obvious-defensive-progamming mode:

NO_ONCE_ONLY_WARNINGS_ZONE:
{
    no warnings qw(once);
    . . .
    use warnings qw(once);
}
[download]

I am often told this is overkill: usually by people that do a lot more debugging than me :-)

Regards,

PN5