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.
|Replies are listed 'Best First'.|
Re^3: On Commenting Out 'use strict;' (errors)
by tye (Sage) on Aug 11, 2005 at 16:15 UTC
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.
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:
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.
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:
By all means pillory me for past mistakes...I've surely made enough of them. But let's make them *actual* mistakes, huh?
by tye (Sage) on Aug 12, 2005 at 20:38 UTC
Thanks for the clarifications. I apologize for my mischaracterization.
I don't consider the LIMITATIONS section of Switch to be even close to adequate. It mentions rather specific limitations in parsing which is likely to give the opposite impression from the Perl6::Rules disclaimer that I quoted. That is, they imply that other than these few exceptions, the parsing of complex code is unlikely to be a problem.
But I've seen reports of problems that are not covered by any of the specific cases listed (such as the contents of comment lines causing very random-looking problems). Does the module always correctly distinguish a '/' character for division from a '/' character that starts a regex (which requires tracking prototypes), just to pick one example?
I once started writing code that would use Inline::Files but quickly switched to a different method when I realized that the module used a source filter. I felt that the problems I'd seen reported for Switch justified a disclaimer like the Perl6::Rules one I quoted and, since neither Switch nor Inline::Files contained anything close to that, I did not feel I could trust Inline::Files at all.
So, personally, I suggest modifying the documentation of these modules to make the (rather wide, no?) distinction clearer.
I apologize again for the unfair thrashing. I hope the above helps to explain the misunderstanding that lead to my confusion.