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

[tlm]

I would say that IMHO there are no trivial error messages...

Step back for a second. What you just wrote is about as defensible as the statement "IMHO there are no bugs."

You want to see a trivial error message? Here, stick this anywhere in your code:

die "I'm sooo not trivial!";

A trivial error message or warning is nothing more than a design bug.

Consider for example the warning

Useless use of a constant in void context

If you read the follow-ups to Why no warnings for 1 in void context?, you'll learn that perl has a special check so that this warning is omitted if the constant is 1 or 0, or a few other esoteric values. I don't know about Larry (or whoever coded that particular bit of perl), but I'm sure that if it had been me who coded that I would have missed adding these checks first time around, and only figured that I needed them after seeing how perfectly sound code was suddenly spitting useless warnings. I.e. there is no a priori guarantee that warnings are non-trivial; this is only a function of the skill of the programmer.

My point is that, the flip-side to the OPs observation is the burden on programmers to make their error messages non-trivial, that this also requires work, and that the more skilled you are as a programmer in keeping your error messages non-trivial, the less likely it is that users will ignore them.

[bofh_of_oz]

I feel I need to clarify my statement.

When I say "There are no trivial error messages", I mean exactly that: there are no trivial error messages that Perl gives you. I do not consider the error messages produced by or die "blah blah blah" constructs as I consider them a representation of the program logic created by a programmer who (supposedly) knows what (s)he is doing. I also specifically said that I do not talk about warnings - those are _not_ error messages, they are just that - warnings...

What I mean is when you write a script, and run it, and Perl gives you an error message, it means there is a problem that must be fixed or the script won't run (properly|at all). It's similar to writing a resume and not doing a spell check - if it contains misspellings, it will most likely be rejected outright. Unusual grammar constructs etc. can be overlooked - spelling errors are not. Same thing in coding - warnings can be overlooked, errors should not be.

Just my 2 cents...

[Limbic~Region]

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"

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"

[bofh_of_oz]

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"...

[Anonymous Monk]

What I mean is when you write a script, and run it, and Perl gives you an error message, it means there is a problem that must be fixed or the script won't run (properly|at all).

Well, you are right in the sense that whenever Perl gives an error message, it stop execution/compilation. But there are many cases where Perl could have continued - and everything would worked as planned. Triple so in the case of warnings. Consider this program:

    use strict;
    while ($str = <>) {
        print lc $str;
    }

It won't run, because Perl refuses it to compile. But if you remove the generation of the error message and its subsequent refusal to continue, for instance, by removing the 'use strict;' line, out outcommenting the relevant part in the source of perl, the program runs fine. There's an error message, but the program doesn't contain bugs.

And then there are the numerous, pointless, warning messages:

    print (1)
    qw /#/
    $foo + $bar

which you see written as:

    print +(1)
    qw /\#/
    ($foo || 0) + ($bar || 0)

just to please 'use warnings'.

[bofh_of_oz]

First case: yes, the program runs fine. And while I agree that the program does not contain bugs *now*, not declaring variables can become a habit and someday create a BIG problem in a large program (trivial mistake: misspelling), which could've been avoided with "use strict".

It's all about personal preferences, after all. I prefer to use the abilities of Perl to force myself to write flawless programs that do not have syntax errors, do not produce warnings, and do not have (hopefully) logical errors. I came to that point of view when I was coding Basic and then reinforced when dealing with badly written VB programs.

Warnings, as I've mentioned, are a different story. I do not turn them on until I've dealt with errors since I believe that getting rid of warnings is a stage when I "polish" the program to make it not only working, but "flawlessly working".

If you prefer to have flexibility at expense of possibility to introduce hard-to-find errors that could've been avoided in the first place, that's your choice. I'm just providing the grounds/reasons for mine.