http://qs321.pair.com?node_id=491944

Today when I came back to my desk afer lunch I found the new issue of Sys Admin magazine waiting for me - I flipped pages to the first article that caught my attention - I read until I got to Listing 1 "somescript.pl" the first thing I noticed was the lack of use strict; at the top and the second thing, though less of an issue for me was the lack of warnings. I immediatley flipped to the table of contents and scanned for the next article of interest. (A bit of irony was the ad for Stonehenge amidst the pages of the offending article. ) So, is it me? Or does this lack of due dilegence turn others off as well?

Ted
--
"That which we persist in doing becomes easier, not that the task itself has become easier, but that our ability to perform it has improved."
  --Ralph Waldo Emerson

Replies are listed 'Best First'.
Re: Is it me?
by jacques (Priest) on Sep 14, 2005 at 18:04 UTC
    Using warnings and strict is a good, smart practice. But not using them is not always a "mistake". Note, for example, that CGI.pm does not use strict.

    In advice forums, people who *constantly* tell others to use strict/warnings often give me the impression that they know little about Perl or else they would have something more to say. ;-)

      I have to admit that I tend to tell people first to use warnings and strict and try for themselves. It's like the story with the art of fishing ;)

      Ordinary morality is for ordinary people. -- Aleister Crowley
Re: Is it me?
by derby (Abbot) on Sep 14, 2005 at 18:12 UTC

    I'm having a hazy re-collection that this issue has come up before. I believe the reasoning is that most error checking and such is left out of magazines in the interest of conserving space for the core idea of the article.

    -derby
      It's usually left out of the examples/description/synopsis in modules on CPAN too, probably for the sake of simplicity and clarity. I notice that a lot of the posts here leave it out (probably for the same reason), even by people who I'm sure use them when they write real code. It would say it depends on the nature of the code; is it demonstration, or is it meant to be used as-is?

      So no, I don't immediately discount code if it's missing a use warnings.

      In such cases it is generally a good idea to say explicitly that error checking has been omited for the sake of clarity.

      The danger of not including the checking and of not making it clear that there should be error checking, is that such code becomes the example that people follow.


      Perl is Huffman encoded by design.
Re: Is it me?
by monarch (Priest) on Sep 15, 2005 at 07:55 UTC
    Was every school teacher that you had an authority on the subject they were teaching?

    Was every presentation you ever went to one of quality?

    I only ask, because I view articles much in the same way as anything in life - it is a person's opinion; they are not necessarily a distinguished individual in that field, they are merely presenting something for fame, credit, or money.

    I've learnt a lot from magazines, particularly in my teenage years when I was thirsty to learn anything I could about programming and computers; these days I rarely, if ever, buy magazines - there's plenty of information to be had from open source code, online manuals, and news articles (and PerlMonks of course!).

    As some others have commented, I don't believe it is necessarily a crime to present bad quality source; an individual who is interested enough will learn from experience why certain coding styles (such as use strict) are a good idea. I know I've learnt a lot of programming lessons the hard way.

Re: Is it me?
by chas (Priest) on Sep 14, 2005 at 18:22 UTC
    If a script is developed (using strict and warnings), and is considered complete and working as expected, is there a reason to leave the use strict (or warnings) turned on? I suppose it doesn't hurt and could be useful for someone else who might edit the script, but other than the latter possibility, I'm really not sure.
    chas
      Most of the time, you don't get 100% coverage when you test things. That means there might still be a situation where something unexpected goes wrong, and a useful warning helps you track down what it was.
      I would leave them there as well, if for nothing else than the general sense of good Perl style they advocate.

      Ted
      --
      "That which we persist in doing becomes easier, not that the task itself has become easier, but that our ability to perform it has improved."
        --Ralph Waldo Emerson
      Well, in that case, you would want to keep them in there since programs are almost never "complete" including your own.
      ...is there a reason to leave the use strict (or warnings) turned on?
      Flip that around -- why would you turn it off? If you can't justify turning it off, then it should stay on.

      Brainstorming here, possible reasons to turn strict and warnings off:

      Speed: Not performing all of those compile- and run-time checks is bound to improve speed. Only benchmarking will tell if it's a real gain or not.

      Confusing users with warning messages: If code spits out warning messages, it should be for a good reason, and it should be meaningful to the user. For example, if the file doesn't exist, that's something the user should understand. If the Beeblebrox is in Ratzafratza, then maybe the message should be changed to something like:

      The Beeblebrox is in Ratzafratza. This should never happen. Please contact the maintainer of this script.
      If your code sometimes innocuously spits out warnings that you know don't make any difference, for maintenance reasons you are better off to use no warnings around the offending statement, rather than turn off warnings everywhere.

      Laziness: OK, I'm not sure how this would apply.

      Hubris: Umm, I'm really not sure how this would apply.

      Any others?

      -QM
      --
      Quantum Mechanics: The dreams stuff is made of

      Leave it in. People forget to put it in, turn it on, flip the switch and diddle the nob. It doesn't really impact performance beyond negligible.

      Lord knows how many time I've forgotten nuances and rules of things to check when things break. When things aren't working right, make it obvious. Use strict.

      (paid for by the strict.pm party. strict.pm for prez, 2008!)

      ----
      Give me strength for today.. I will not talk it away.. Just for a moment..
      It will burn through the clouds.. and shine down on me.

Re: Is it me?
by samizdat (Vicar) on Sep 15, 2005 at 13:42 UTC
    In my mind, code in magazines and on the Net is always 'buyer beware'. Code in shrink wrap is no better, but at least with open source, you have a choice. As a programmer, you have an *informed* choice. Certainly the 'use x & y' mantra is oft enough repeated around here that anybody beyond the Rabbit-book level is educated enough to be aware of what those pragmas can do for you, if not necessarily what they can do _to_ you.

    I've written for print mags and online before, and I always distill my code down to the essence because if I don't, the editor will take a meataxe to it. The point made upthread about explaining the omission is a great one; I'll add a para to my future texts about that because I'm always out to educate future proggies to give them a chance to become better than me... :D