Re^5: On Commenting Out 'use strict;'

bofh_of_oz,
Ok, I am a big advocator of using the strict and warnings pragmas as well as the diagnostics when necessary. With that said, how does a novice distinguish between a warning an error. Consider the following 1 liner

perl -e "my $foo; my $bar = 3; $bar += $foo; print $bar"
versus
perl  -Mwarnings -e "my $foo; my $bar = 3; $bar += $foo; print $bar"
[download]

Perl's DWYMery silently converts undef to 0 for us without warnings producing the correct answer in both cases but with warnings it warns me of a potential problem. In fact, Perl isn't consistent in its warnings:

# ++ is a short cut for $foo = $foo + 1
perl  -Mwarnings -e "my $foo; $foo++; print $foo"
[download]

Cheers - L~R

Comment on Re^5: On Commenting Out 'use strict;' Select or Download Code

Replies are listed 'Best First'.
Re^6: On Commenting Out 'use strict;' by bofh_of_oz (Hermit) on Aug 11, 2005 at 14:08 UTC
Somehow, I believe you've answered your own question. If you do not turn the warnings on, you do not get warnings to show up. What I usually do is enable "use strict", make the script compile and produce the results I expect (therefore, ensuring the errors are dealt with), then turn on "use warnings" and polish the script until all the warnings are gone. It's like "deal with the prolems first; make it nicer later"... -------------------------------- An idea is not responsible for the people who believe in it...	[reply]
Re^7: On Commenting Out 'use strict;' by Limbic~Region (Chancellor) on Aug 11, 2005 at 14:51 UTC
bofh_of_oz, Somehow, I believe you've answered your own question. No I didn't, you did. Your answer is that the novice can distinguish errors from warnings by using strict only first. After getting it to compile and produce the correct results, they can add in warnings to polish it off. Why does one need to fix any of the so called errors if the code produces the correct results? The strict pragma really doesn't do much other than force you to declare your variables and not use them as symbolic references. Neither of those things absolutely means error as both can be ignored and still produce the correct results. Why then are they errors in your opinion that must be fixed? My point is not to say it is ok to write code that isn't compliant with strict and warnings. My point is that for the initiate in the language, learning the why the warning or error is being spewed forth is much more important then making it go away. This takes time and effort. Not all messages from strictures need to "fixed" as you say. I have intentionally used symbolic refs to manipulate the symbol table. Fortunately for us, both pragmas are lexical and can be turned off when the message doesn't fit the crime. Understanding the why behind the message lets us know when it is ok to do that. Cheers - L~R	[reply]


more useful options
	PerlMonks