in reply to Re^2: Should Test::Most import strict and warnings?
in thread Should Test::Most import strict and warnings?

Well, yes, I would be against perl5i and Modern::Perl (sorry). I find autodie and utf8 acceptable (note, both are all-lower names) primarily due to their very limited focus — they each do one thing for me not several things that are all related to each other only by way of being good for me. It is important to me that autodie limits itself to modifying built-in functions, and I would be opposed to autodie enabling strict.

I'm all in favor of understanding over coddling, but constant worry about what strange things a normal looking module might do is not fun me or the newbie. perldoc should be ready at hand, but choosing long_descriptive_function_names is encouraged so that code skimming is possible, why should loading a standard-looking module be a minefield of potential (well-intentioned) "magic" (meaning anything other than importing a few subs)? Already there are those who discourage adding subs to @EXPORT, claiming that everything should be in @EXPORT_OK so that even imported functions are explicitly listed.

If Test::More were an all-lower named module it could get away with enabling strict, but a proliferation of lower-case modules is not good either — one should have a good reason for building one. And, yes, that means I have less opposition to common::sense than to Modern::Perl simply because the former advertises "something more than function importing happening here", but I would not use either and would rather not see either in any code I run across.

Update: Forgot to add that autodie and utf8 both provide a service that can be very difficult to do without them. Typing 5 extra lines listing explicitly the modules I want to use is not considered "difficult" by me.

Good Day,
    Dean

Replies are listed 'Best First'.
Re^4: Should Test::Most import strict and warnings?
by chromatic (Archbishop) on Feb 08, 2010 at 21:00 UTC
    Typing 5 extra lines listing explicitly the modules I want to use is not considered "difficult" by me.

    Five extra lines in every file, at least one extra line in every method, and pretty soon you have a lot more code than you need.

[reply]
      Define "a lot." 5 lines per file and 1 line per function is at worst 150 percent more code (with one-line functions and one-function modules). If you're dumb enough to write code like that, I don't want to use it. If your code imports random modules into my code, I don't want to use it. If you can't either type out your boilerplate of choice or get your editor to do it for you, you probably shouldn't be a programmer.

      Your acolytes will use "chromatic::Perl" (evidently a pragma...). Other people don't want your religion.

[reply]
        Define "a lot."

        A non-zero amount of unnecessary, repetitive, boilerplate code. You know, the kind we laugh at Java programmers for having to write because they can't say say 'Hello, world!' without creating classes and class methods and conforming to the proper signature of the main() method in a class of the proper name stored in the proper place in a filesystem hierarchy.

        If you're dumb enough to write code like that, I don't want to use it.

        If you're bad enough at communicating that you have to resort to personal attacks to punctuate your points... well, you're free to use software to which I've contributed anyway, because that's what free software means.

        If your code imports random modules into my code....

        If my code did that, I wouldn't use it either. Fortunately, it doesn't. It does exactly what the documentation says it does. You're also free to read the implementation to see exactly what it does. It's short. It's simple. It's straightforward. Certainly you're more than capable of verifying for yourself what happens.

        If you can't either type out your boilerplate of choice or get your editor to do it for you, you probably shouldn't be a programmer.

        If you don't see the value of removing boilerplate and preventing its spread and ensuring that no one—especially a novice‐ ever has to worry about setting up the proper editor or understanding all sorts of crazy black magic to grovel in an attempt to convince Perl to help him when it's perfectly capable of doing so, well, we have very different ideas about what makes a programming language usable.

        Note, for example, how much more test code people have written in Perl since the advent of Test::More and the removal of "black magic here... don't edit" at the start of every test.pl file you could find on the CPAN circa 2000. That's no coincidence.

        Other people don't want your religion.

        Histrionics have no place in serious discussions of programming.

[reply]
[d/l]
[select]

        Here something from my test suite:

        find t -name *.t -or -name *.pm | wc -l
301

        [download]

        With strict and warnings included, that's actually six lines of code saved for every file, or roughly 1,800 lines of code I didn't have to write or remember not to forget.

[reply]
[d/l]

In Section Seekers of Perl Wisdom