Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re: On Commenting Out 'use strict;' (errors)

by tye (Cardinal)
on Aug 10, 2005 at 22:44 UTC ( #482793=note: print w/ replies, xml ) Need Help??


in reply to On Commenting Out 'use strict;'

Eons ago, when I worked in the student lab for a bunch of VMS terminals, I'd ask the approaching student "What's the problem?" and often get "I'm getting all of these errors." Only a couple of times, I responded that "If the errors are the problem, then let's get rid of those" and then typed1:

$ set message/nofac/noid/nosev/notext

and walked away and waited for "That worked great. But now I can't get it to produce the output that I want."

It is my experience that most computer users don't appear to attempt to understand the error message they are given. Ever notice that many root nodes mention that errors are produced but don't actually say anything about the contents of those errors? Many nodes don't even mention the presense of errors despite it turning out that error messages were output. Many people don't bother to include $! in their own error messages (in large part, I believe, because many people don't attempt to understand the error reasons that $! provides).

Of course, many error messages are hard to understand. So eventually giving up at trying to understand error messages is not too surprising of a result.

People turn off "use strict" because they don't understand the "noise" (a telling word choice) that results.

So you have to help people learn how they are supposed to try to understand an error message. And sometimes you just have to help them understand the specific error message that is right in front of them.

For strict, I'd show them a simple example of mistyping a variable name and provide the two ways to "fix" the error: 1) correct the spelling of the variable name, 2) comment out use strict. If they actually pick (2), then show them that the program doesn't work. More likely, they pick (1) and then you can explain that the error message was helpfully pointing out a problem and that is the purpose of error messages. Then you can discuss how pointing out mistyped variable names doesn't work unless you declare every variable you use and skipping that step only makes sense for quick hacks.

But, yes, watching people ignore error messages can get frustrating. (:

Update: And in your particular case, I suggest getting "use strict" added to the company's coding standard practices so you can just leave as soon as you see it commented out.

- tye        

1 This command turns off all parts of system error messages, which is a bit like persistently doing 2>/dev/null.


Comment on Re: On Commenting Out 'use strict;' (errors)
Select or Download Code
Re^2: On Commenting Out 'use strict;' (errors)
by Anonymous Monk on Aug 11, 2005 at 12:28 UTC
    For strict, I'd show them a simple example of mistyping a variable name and provide the two ways to "fix" the error: 1) correct the spelling of the variable name, 2) comment out use strict.
    Of course, if their program is just missing the 'my' (and doesn't contain other bugs), 1) doesn't apply, and 2) shuts off the error messages, and generates the correct output.
      Of course, if their program [..., then it] doesn't apply

      It wasn't meant to apply to their program. It was an example meant to address their apparent lack of understanding of or even effort to understand error messages. If you "use strict" and then don't "get" why you get the errors you do, then you really didn't do any work investigating what the point of strict.pm is before using it. And if you bring code you were paid to write to a code review with "use strict" commented out because of that, then you are a fool. So there is a failure there that is more basic than whether 'use strict' applies to their coding or not.

      Now, whether the example of mistyping a variable name "applies" or not is another issue. I suppose there are people who think they never mistype variable names. Or that they'll notice the mistyped variable name because they have great methods for preventing bugs (such as rampant unit testing). And I'll agree that rampant unit testing can reasonably be relied upon to find mistyped variable names. But that just means that the one example may not apply to a situation that wasn't the point of the example.

      if their program is just missing the 'my'

      Then they are using global variables, which again puts us in the realm of "quick hack" coding. And even rampant unit testing isn't enough to find the types of problems that can sneak in when you don't use "my" and write more than a "quick hack". And, when getting paid to write code and doing a code review, it doesn't matter if you are writing a quick hack or not, you shouldn't be writing in a "quick hack" style.

      And unit testing is great at finding bugs in units. And so along with unit testing you need to isolate the units and minimize the chatter across unit boundaries. And not using "my" means you haven't done that.

      Now, if someone had said they don't "use strict" because it never finds bugs for them, then that would be a different situation. Or if they can't follow a logical argument or don't care to learn about improved coding practices, then that is a different situation as well. But these would all be indications that they shouldn't be working at a company I want to work for.

      Sure, you can be a genius and not see the value of 'use strict'. For example, TheDamian wrote:

      I rarely use strict in my modules...because I rarely make the kinds of mistakes that use strict catches and (more importantly) because I know to turn it on when confronted with an otherwise-mysterious bug.

      So he didn't see the value of 'use strict' to report bugs, only to narrow down bugs that he notices via other means.

      But, to be quite frank, TheDamian was a fool. (: To see this you need only note that many modules he wrote that were meant to be useful used source filters and it took him years to realize and own up to the fact that these modules were seriously flawed because of it. Quoting him more recently:

      via a source filter. (And hence suffers from all the usual limitations of a source filter, including the ability to translate complex code spectacularly wrongly).

      The "difficulties" of parsing Perl code were well-known back then and he wrote the source filters and so should have understood their limitations well and so producing modules that relied on source filter the way that they did without a disclaimer like above was rather foolish, IMO.

      And quoting him more recently again:

      1. Always use strict and use warnings.

      There are certainly places where not using 'strict' is not only appropriate but useful. But those cases don't apply to the situation discussed in this thread.

      - tye        

        But, to be quite frank, TheDamian was a fool. (: To see this you need only note that many modules he wrote that were meant to be useful used source filters and it took him years to realize and own up to the fact that these modules were seriously flawed because of it.

        No doubt I *am* a fool in many many ways. But this particular justification for that conclusion just doesn't hold water. The *only* module it might conceivably apply to is Switch.pm, which specifically has a LIMITATIONS section in the POD, clearly explaining the potential problems.

        The only other modules I have released that use source filtering at all are either:

        • in the Acme:: hierarchy and hence inherently stupid and NOT FOR PRODUCTION USE,
        • in the Perl6:: hierarchy and hence inherently experimental and NOT FOR PRODUCTION USE, or
        • don't actually filter *source* at all (i.e. Inline::Files, Smart::Comments, Toolkit) and hence are unaffected by the parsing limitations of source filters.

        By all means pillory me for past mistakes...I've surely made enough of them. But let's make them *actual* mistakes, huh?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://482793]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (9)
As of 2014-08-20 23:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (125 votes), past polls