in reply to Re: Coding styles: OOP vs. Subs
in thread Coding styles: OOP vs. Subs

Or, everything is fine, and the warnings are wrong. Note that warnings are generated when Perl thinks the programmer made a mistake - if Perl would be sure, it would have thrown an error.

I've removed 'use warnings' from programs as well, after getting tired of adding 'no warnings' all over.

Perl --((8:>*

Replies are listed 'Best First'.
Re^3: Coding styles: OOP vs. Subs
by wazoox (Prior) on Nov 17, 2005 at 16:06 UTC
    I'm surprised; "use warnings" saved my a** a couple of times, and the overhead is really small :
    $ wc -l *.p* | tail -n 1 6949 total $ grep "no warnings" *.pl | wc -l 8
Re^3: Coding styles: OOP vs. Subs
by dragonchild (Archbishop) on Nov 17, 2005 at 16:11 UTC
    I'd be interested in seeing what kinds of programs those are. Other than throwaways, I have very rarely run into problems with warnings. The most common warning I see is "undefined value used in ...", which is alerting me to a real bug. Sometimes, I think I should turn the undefined warning into a fatal error, but I'm too lazy to do it. :-)

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      Here's a one-liner where Perl emits two warnings - both wrong.
      $ perl -le 'use warnings; print ("$_") for qw /foo, #bar/' print (...) interpreted as function at -e line 1. Possible attempt to separate words with commas at -e line 1.
      And yes, I know what the warnings are for. And I know how to code around them. The warnings are still wrong though.
      Perl --((8:>*
        That still seems like bad form to me. Imagine someone comes along and tries to extend it...
        use warnings; print ("$_")."blah" for qw /foo, #bar, BAZ/
        Just because you can do something doesn't mean you should. (Not that I'm implying that you should never turn off warnings. The OP's code isn't one of those times though).