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 typed¹:

 $ set message/nofac/noid/nosev/notext
[download]

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.

For 90% of the problems I see, there are three main solutions:

• Plug in the loose cable / turn it on.
• Read the error message, and do the obvious thing.
• Get a mechie to fix a broken part.

Solution #2 there is the hardest to train, but is the most rewarding. I have often heard "... just teaching me to read again..." said with a smile. (Attitude and atmosphere are very important)

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        

Well done. Many people seem willing to sacrifice what they know are absolute minimum standards in order to get the job "finished".

In a previous project I worked on, not just the programmers but also the project management had fallen to this rubber-stamping dark side. In one case people were left out of a code review, since their (expert) comments would presumably slow things down. I've seen more than one review announced out of the blue for a major piece of code (>10K lines) just a few days before it occurred. I think the classic case occurred when a review consisted mainly of people that didn't know the language the code was written in, so I'm sure the review went smoothly.

I feel your pain OGB~! In my experience I had a GREAT instructor! You guys on here and my prof in college who enlighted us on Perl. He always said, "never turn off strict", and always comment your code when time permits, but don't leave it out.

After college I got this really cool job as a systems admin using Perl on windoze, I walked into a shop with shaky code, no comments and not a hint of strict~! After fixing programs and converting their unix like utilities to work on windoze the powers above decided to change their web server to windoze. While two of us rushed to learn .asp .Net came along and this web interface needed to be done. So they decided to hire a student who was fresh out of college who knew .Net and has a father who is a .Net programmer. This kid finished the project in record time but me and this other person would be maintaining it (the web person for the web aspect and me for the programming aspect), anyway this other person was skeptical because some of it was in .Net and some of it was in .asp and she didn't like that there wasn't any comments anywhere? I approached the boss and said HEY we need to get this guy commenting his code, this is scary!! I looked at the .Net code and it was ALL over the place, calling here, going there, coming back going there and not a single line of comments!

About a month later the kid comes back to fix some bugs and work on commenting. The kid leaves with everything working (maybe) and one day I go in some of his code to look and low and behold I see these kinds of comments 'global variable' 'private variable' 'helper function' I was in complete awe.... I have since left that college because of it, but I will never stop using Perl.

FU CU

I fairly recently gave some perl coaching to a VB programmer who has been dabbling in perl scripts. He had a problem that required some debugging; I introduced him to the delights of perl5db and we found the problem - a typo in a variable name.

I then explained to him about use strict; and he agreed it was a good idea, and should be in any agreed coding standards. I also asked him whether he would conceive of having production VB code without "option explicit". He took my point.

--

Oh Lord, won’t you burn me a Knoppix CD ?
My friends all rate Windows, I must disagree.
Your powers of persuasion will set them all free,
So oh Lord, won’t you burn me a Knoppix CD ?
(Missquoting Janis Joplin)

This kid finished the project in record time but me and this other person would be maintaining it (the web person for the web aspect and me for the programming aspect), anyway this other person was skeptical because some of it was in .Net and some of it was in .asp and she didn't like that there wasn't any comments anywhere?

Now you got me going -- I feel your pain as well. If I don't like rubber-stamp reviews, I really don't like it when management brings in "free" help. Any monkey can be really productive writing code with no design, comments, etc since banging out code is about 25% of what you need to do (if that). The project I mentioned in my previous post also had a case like this. They decided to let some folks half way around the world update a major server. These apes inserted comments in a foreign langauge, had huge indented sections of code with gargantuan variable names, bad memory leaks, and they just dropped it and the abyssmal documentation in our laps to support.

Now that I think about it, I think my life mirrors Dilbert...

It didn't understand use strict; properly - then you'll provide it with good reading.
Here, at the monastery, there are plenty of excellent articles about this subject.

Much worse will be if this child refuses to learn and did not respect your programming practice when you're explained it about 'strict' - but presumably this is not the case. You just tried to not get angry but anyways got angry when a person did not understood obvious for you thing.

I learned from many articles here, that good programming is about learning many things (programming techniques, behaviour in the office, corporate etiquette, and many many things).
You should give a chance to learn to the child.

If I had been there, the conversation would have gone something like this.

name used only once

You are either putting data into a variable and not getting it out again (which seems pointless) or trying to get data out of a variable that you haven't put data into (which seems stupid).

global symbol requires package reference, things like that

Your code has variables that can be (accidently!) used outside of the necessary scope. This is dangerous.

It cluttered up the SYSOUT and made it hard to find the real bugs

This are the real bugs. Fix them.

Your code has variables that can be (accidently!) used outside of the necessary scope. This is dangerous.

Yes, but it's good to realize that "use strict" doesn't magically fix that. Accidently using variables outside of the necessary scope happens when variables are defined using a scope that's too broad. It's pretty hard to accidently use variables from a different package - you would have to explicitely point to that package. Problems are cases like:

$var = "whatever";
sub foo {
    ...
    while ($var = <HANDLE>) {
        ...
    }
    ...
}
sub bar {
    ...
    foo();
    ... code assuming $var is unmodified ...
}
[download]

Slapping a use strict; on top of the code, and putting a my in front of the first occurance of $var doesn't solve this problem - although it makes use strict very happy.

What does solve the problem is declaring a lexical variable my $var, or a local value local $var inside foo(), neither of which actually requires use strict.

use strict is a tool. It ain't no magical bullet.

The reply was, and I quote exactly: "You know, name used only once, global symbol requires package reference, things like that. It cluttered up the SYSOUT and made it hard to find the real bugs."

Sounds like management material to me...

I'm with you 100%, but let's turn the question around: what does your story tell us about how to implement our error reporting? It's a "cry wolf" story: too many trivial error messages devalue all error messages. I have noticed that, over time, perl has become increasingly smart about error messages; "false" error messages get weeded out. There's a lesson here: effective error reporting is hard work; it takes effort to get it right; the simplest solution (i.e. screaming bloody murder whenever something doesn't look quite right without investigating the matter further) runs the risk of having the receiving end stop listening. It's a two-way street: it takes effort to understand what the error messages are saying, but it also takes effort to code an error-reporting system worth paying attention to.

Disagree.

Those PITA warning messages are little hints that the craftmanship of the code is below par. Perhaps one in a thousand warnings can be ignored. The other 999 need to be addressed. An example.

Yesterday and today I had to write quick scripts to get some stuff done on a Production system. Normally I'd do a one-liner or cobble something absolutely horrible together, cross my fingers and go with it.

Instead, I wrote POD, used Getopt::Long to handle arguments, used or die $usefulMessage in all of the appropriate places. Yes, it took a little longer to write, and I tested as I went .. but the result was that these little utilities worked absolutely fine. Then what?

Then I checked them into our version control system so that I would know where to find them the next time I needed them. So now I have documented, commented, error checking utilities that I can pull out of my hat (so to speak) the next time we need to do X.

It all comes down to a matter of craftmanship. If my scripts and modules compile 100% clean, if I never have errors in my error logs, that's a sweet way to be.

So fix your code -- banish all warnings!

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

I think it's a little worse than that. There are a couple of warnings in Perl5 that frequently get triggered without any real problem in the code. I'm thinking most especially of the one when you interpolate a value that might or might not be defined, and it happens not to be. I have never yet once seen a situation where that warning was useful, but many, many times I have found myself introducing excessive verbosity and needless complexity to the code in order to suppress it.

I've also occasionally been annoyed by other warnings when I knew very well about the thing they were warning about but for one reason or another did not consider it a problem, and I wished I could just make the warning shut up.

I heard a rumor that Perl6 is going to give us the ability to shut off individual warnings, without losing the ability to see other warnings. I look forward to that.

Nevertheless, the clown described in the original post is making future trouble for himself and/or someone else.

I would say that IMHO there are no trivial error messages: if compiler/interpreter complains, it is an error and must be fixed before sending code into production. Warnings can be commented out until all the errors are resolved; then, if you have time, deal with small things... but errors should be fixed.

As for our own error reporting - that's for the "logical" errors that Perl cannot catch but they still lead to wrong results - yes, most definitely. That's the second thing I tend to do (after coding the functionality).

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

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!";
[download]

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
[download]

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.

the lowliest monk

That's why a part of best practices should include when to turn off warnings.

If you know a piece of code is going to produce spurious warnings; but not cause any side effects (like the 'uninitialized' that happens all the time); and doing it the correct way gives you complaints from management that it's harder to read you can just add a local $^W immediately before the code.

Harley J Pig

I had a concise, readable, maintainable bit of C code that generated about 9 "possibly incorrect assignment" warnings, because it used assignments inside an if(). Adding parentheses made it ugly, and breaking the input out of the if would have been tricky and would not have increased the quality of the code in my opinion at the time (this was many, many years ago, and many lines of code have passed under the bridge since then, so my deicision now may be different if I still had the code). I didn't want to turn off the "possibly incorrect assignment", and the compiler (Borland Turbo C) didn't have selective warning pragmas that I could wrap the code in. So I left it as it was, and documented that the only warnings generated are this specific group.

Mark Jason Dominus has an excellent list of replies to problems created by that attitude (among others).

Two of my favorites are:

#11920 The error message is the Truth. The error message is God.
#11921 It could be anything. Too bad you didn't bother to diagnose the error, huh?

Lesson: Warnings are there for a reason. You shouldn't ignore a warning unless you have researched it and determined that you actually want to do whatever it is that's triggering the warning. THEN, you go ahead and document that this warning is expected and the reason why it's ok. AND THEN, you have another developer sign off on it. Both your names are in that comment forever and ever, amen!

Personally, in over 10 years, I've never run into a situation where a warning was actually warranted. But that's just me.

When I was assigned to correct some error in one day's processing, I examined every detail item by item, since I wasn't familiar with the system. While the people familiar wth the system could leap from point to point, quickly narrowing in on the error, I had to be as picky as an accountant, verifying everything was correct. As a consequence, I discovered several errors that had been there for years, that no one was aware of.

Moral of the story: the big picture is good, but details are important, especially when they're wrong.

--
TTTATCGGTCGTTATATAGATGTTTGCA

Lesson: Warnings are there for a reason.

Yeah. Too bad some warnings are there because someone thought "I think this is bad coding style, let's issue a warning", and had their patch accepted. Luckely, most proposals like that never make it, but some did.

You shouldn't ignore a warning unless you have researched it and determined that you actually want to do whatever it is that's triggering the warning.

Yeah, but in most cases, it's bloody obvious.

THEN, you go ahead and document that this warning is expected and the reason why it's ok.

# Perl thought I thought that perl thought differently.
# Once again, perl was wrong.
#                                 // Anonymous Monk, today.
no warnings 'some category';
[download]

AND THEN, you have another developer sign off on it.

Right. And next time, have him sign off when I want to blow my nose as well.

Both your names are in that comment forever and ever, amen!

Don't think so.

But you left out the important thing. You don't let the warning be issued, you turn it off using no warnings.

I think we have a fundamental difference in assumption about what code is and what it is not. My assumption is that the code I write is not mine in the way that my underwear is mine. I write code that part of a group's work. The stuff I type in will be edited by someone else and I will be editing code that someone else typed in.

With that in mind, I have to try to write my code as strictly as possible. This means turning on all strictures and warnings. Now, I have, do, and will write code with soft references in it, in violation of strict-refs. I have, do, and will write code that needs no warnings 'uninitialized'.

I suspect the difference between you and I is that I am directly accountable to other people. These people are extremely programmers, but I'm still accountable to them. So, I have to demonstrate why I feel that strict-refs or no-warnings is appropriate.

The thing I always return to is that the warning is describing a potential error condition. By turning off warnings, I'm turning off a error-detector. Sometimes, it is annoying, but it's saved my butt at 3am on Saturday more often than I'd care to admit.

---

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?

I would tend to disagree. I am pretty much "picking up" Perl as I go along, and I never took any Perl classes or finished reading a Perl book (yes, I started reading it, but never finished. However, I've been coding in different languages for last 15 years, and hope I understand the value of commenting/testing my code. So, when I was learning Perl, and I just found out about "use strict", I have this option in every one of my scripts - especially in production (even though someone here in PM told me I don't need it in production as the bugs were fixed in dev/testing phase).

In my opinion, it is the people who don't care about the result of their work or just can't think logically would comment out "use strict".

And I agree with you that such people should be educated. I usually say to them "If I place a high-voltage transformer box here, all warning labels from it, and make you maintain it - would you do it, and how comfortable would you feel?". There's nothing like real-life examples...

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

I would only point out that you are an exception to the rule, in my experience that is.


If you give a man a fish he will eat for a day.
If you teach a man to fish he will buy an ugly hat.
If you talk about fish to a starving man, you're a consultant.

I just reread this node (it popped to the top yearly best nodes) and this line:

I stared at Him for a good fifteen seconds. Then I got up and left the room.

just cracks me up. Kudos. Do you offer any lessons on how to do this well? I need to use it on our marketing people. My standard response to these situations has been to say "that's just silly." The silly line is quite effective in getting developers to rethink their entrenched stances but those marketing folks need something stronger.

Update:

In the afternoon, I wandered over to my manager's cube. I explained why I had been so sour all morning. We talked for a bit, and then she said: "I've been looking at that book you brought back from the Con last week (Damian's 'Perl Best Practices'). Did you look at that first appendix? The one with the Lists of Tens? And the second appendix?? I see what you meant when you said that we don't need to write our own Perl coding standards, Dr. Conway already has."

She chatted with her boss, the VP-Engineering, some time later in the day. This morning the VP-Eng wandered by my cube and told me that he had just put in an order at Barnes&Noble for 25 copies of 'Perl Best Practices', and he whats to know if there is a Java equivalent.

Your company is not the only one. liz is doing quite a bit of work in Perl for another company, and she introduced the book there too. They bought a pile (less than 25, but still...) of the book and use it now for their Perl coding standards as well. Wonderful book. They still need some convincing on best test practices, but they're getting there, one step at a time...

It's Because They Are Telling You Something About Your Code; It's Buggy!!!!

Yes, it's good to turn on strictness. It's good to turn on warnings. But it's only useful if you understand the messages it issues. Its messages indicate the code may have a problem spot. But it doesn't have to be, and perl may be wrong to. The conclusion that "oh, it gives messages under strict/warnings, hence the code is buggy" is too shortsighted, and a signal of poor understanding of Perl.

Note that I'm not claiming the code you refer to doesn't have bugs - it probably has. I'm just ranting about your generalisation.
</rant>