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 [..., 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?