On Sat, Feb 17, 2001 at 01:31:27PM -0800, Edward Peschko wrote:
> > I thought that was the problem you were having. Forgetting to type
> > "use strict" in your programs.
>
> No -- its *anywhere* that you write scripts/modules/what have you. Anywhere
> you miss it, it is a syntax error to me.
I agree that strict is good. I agree that warnings are good. I agree
that I would impose this blessing on any project I'm involved with.
However, I will not try to enforce this on the world. Don't use a
language as a style hammer.
That's the last I'm saying on that subject. I'll agree to disagree.
> > Modules? Modules should have test suites. A simple test would be to
> > check for /use strict/. Of course, you *are* writing test suites for
> > all your modules, right??
>
> Of course - ultimately I write test suites. I however don't write
> test suites when I'm first iterating code and design. Why the hell
> would you write a test suite when your interface is changing?
I write my docs and tests in parallel with the code and change them as
my interface changes, though the interface typically doesn't change
radically since I think it through fairly well as a result of having
to write the docs. At the very least I have a test script which makes
sure the module compiles (in your case, it would check for strict).
print <<IRONY;
I consider a module without tests or documentation to be a syntax
error. Maybe perl should refuse to run a module without POD and
MakeMaker should refuse to install a module without tests unless given
a special flag. Then people will sometimes forget to use that flag
and they'll be reminded of the importance of writing documentation and
tests.
IRONY
Its a good idea to write docs and tests, but I'd never try to impose
my style on every Perl programmer.
> So go back to my original post. My argument is that it is going to
> be a process of weaning people off of *not* using strict and
> warnings. And my point is that people will start with '-q', and
> probably use it most of the time. But once in a while, they will
> forget.
>
> And when they do, they will either immediately add '-q' to their scripts and
> ignore the warnings, or they will actually think about the errors that are
> coming on their screens.
Unfortunately at this point, they will probably be overwhelmed with
warnings and fixing their program to run clean will take a relatively
large effort. The benefit will not be clear, it'll just look like
lots of busy work.
The problem is, fixing errors (and warnings) should be an iterative
process. The way you expect -q to be used discourages this. There's
nothing worse than suddenly seeing a flood of warnings from your code.
We've already been around in circles on this. As above, I'll agree to
disagree.
> > If you're using their module, their bugs ARE your bugs! If
> > something's throwing warnings in your program, you fix it. Whether
> > you wrote that part of the code or not. Perl doesn't care who
> > authored what part, it'll make the mistakes just the same.
>
> Right, but its a question of priority - by making warnings the default we force
> ourselves to be more careful. We sure as hell can't tell people 'use -w' if we
> don't believe it ourselves.
>
> And its a question of *usability*. Look at the following piece of code:
>
> use Carp;
>
> my $a = undef;
> carp($a);
>
> When I run this under 'use warnings', I get the following.
>
> Use of uninitialized value in join at
>/home/edwardp/install/lib/perl5/5.6.0/Carp/Heavy.pm line 164.
> Use of uninitialized value in join at
>/home/edwardp/install/lib/perl5/5.6.0/Carp/Heavy.pm line 31.
>
Let's use this as a test case of the wonders of making warnings
default and the magical results it will have on cleaning up the perl
core libraries. You are aware of a bug, you're even rather annoyed by
it, and you're accutely aware of its existance due to a warning. But
you've done nothing about it.
Why haven't you fixed this? Why haven't you even reported this?! Why
isn't this a test case??
I'm sorry if this sounds like a personal attack, but its a perfect
illustration of how easily and often minor warnings are ignored and
how turning them on isn't going to make a dent in the community's
psychology towards minor warnings. Even you have the subconscious
attitude "oh, somebody else will fix it" (unfortunately, that somebody
is too often me, Perl's garbage man).
The fix, BTW, is simple. The warning points directly to the problem.
A minute spent examining Carp::Heavy shows all that's necessary is to
remove the assumption that @error is defined (this is the Carp::Heavy
from bleedperl).
- my $err = join '', @error;
+ my $err = @error ? join '', @error : 'undef';
And then to write a test to ensure it doesn't happen again.
If you're not willing to do it, why should you assume anyone else is?
I can't fix up the whole distribution alone.
Ed, you're your own counter-example. You'll find you're not the only
one, few people want to do this sort of work.
I'll stop the argument there, I think we've yelled at each other long
enough. Write up the RFC if you'd like, but I'd request that you
provide a pointer to this specific post. I think it most elegantly
sums up my objections.
