http://qs1969.pair.com?node_id=482954


in reply to Re^3: On Commenting Out 'use strict;'
in thread On Commenting Out 'use strict;'

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

--------------------------------
An idea is not responsible for the people who believe in it...

Replies are listed 'Best First'.
Re^5: On Commenting Out 'use strict;'
by Limbic~Region (Chancellor) on Aug 11, 2005 at 14:02 UTC
    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"

    Cheers - L~R

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

        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

Re^5: On Commenting Out 'use strict;'
by Anonymous Monk on Aug 11, 2005 at 13:55 UTC
    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'.
      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.

      --------------------------------
      An idea is not responsible for the people who believe in it...

        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".
        I never said 'use strict' wasn't a good idea. I just want to point out 'use strict' isn't a magical bullet - it doesn't find all the bugs people something think 'use strict' will avoid, and it has its share of false negatives as well.
        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.
        That's exactly the sentiment I warn against. There is no such ability in Perl. 'use strict' or 'use warnings' don't force you to write flawless programs. They certainly don't prevent you to write syntax errors (and if you do, they don't find them either - the compiler will though). 'use strict' is more like a harsh driving school teacher that slaps you and puts the car in neutral when you don't look in the mirrors. But just looking in the mirror won't prevent you from crashing the car - and you're a worse driver if you think all you need to do is look in the mirror. Looking in the mirror is a good thing, but it doesn't stop there.
        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".
        I have a hard time of believing that's an efficient way of developing a program. I always start with 'use warnings', and then when a warning pops up, I fix the cause, or (locally) turn of the warning, whatever is appropriate.
        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.
        Once again, I'm not advocating to leave out 'use strict'. I'm just pointing out it's just a tool - not a magic bullet.