http://www.perlmonks.org?node_id=819692

If you've been following the questions/answers posted here for any length of time at all, you will have no doubt seen many examples of problems that were fixed (or could have been avoided) if the programmer had simply put "use strict;" at the beginning.

If I recall correctly, "use strict" was introduced with perl5. There were changes in the language such that older perl4 code might break. So the only time anyone should ever NOT "use strict" is if you're running perl4 code with a perl5 interpreter, and want to be in "backwards compatibility mode".

Now, seeing as how perl5 has been in wide use for over 10 years now, and seeing how many problems could be solved and/or avoided: why can't "strict" mode be made the default?!?!

Anyone who really needs backwards compatibility (or wishes to bend the rules for a very good reason) can type something to turn strict OFF (i.e., "no strict refs", etc.)

I think this would help more than it would harm.

Has anyone else ever thought this way? Agree? Disagree?

Replies are listed 'Best First'.
Re: use strict
by JavaFan (Canon) on Jan 26, 2010 at 15:07 UTC
    Has anyone else ever thought this way?
    Yes. People have argued for that many times at p5p. But p5p is (IMO rightly so), extremely careful not to break their customers (that is, anyone using perl5) code by doing a simple upgrade.

    If you make strictness a default, code will break. That gives a lot of negative karma for Perl. It's decided it's not worth it.

    Oh, and if you argue "but adding no strict; isn't that much work", then I counteract with use strict; is only one character more - so, it's not much work, is it?

      Oh, and if you argue "but adding no strict; isn't that much work", then I counteract with use strict; is only one character more - so, it's not much work, is it?

      Hmmm, very strange argumentation. Having strict on by default would need 12 characters less (including the final newline), and that for everyone who thinks that strict mode is a good idea, as opposed to the few people still working with Perl4.

      Having strict on would break a lot (but propably not all) of ancient Perl4 code, and for a good reason: New version, new rules. If you want to run Perl4 code, use a perl4 executable. Or add no strict; or a hypothetical use perl4;. Or port the code to Perl5.

      One could discuss to turn on strict mode only for "real" scripts, and not for quick command line hacks (perl -e ...).

      And the same applies to the step from Perl5 to Perl6. Yes, I'm aware that a Perl5 mode for Perl6 is at least discussed, if not planned or already implemented.

      And yes, I'm aware that this discussion won't change Perl5, and it's too late now to change Perl5 to have strict mode on by default. But at least we can learn this lesson for Perl6.

      With the new operators for 5.10, we see a very similar problem: Backwards compatibility at every cost, even if it makes writing modern Perl harder. Modern::Perl is a pretty neat idea, but it is not a core module and it cures the symptoms, not the root cause.

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
        Having strict on would break a lot (but propably not all) of ancient Perl4 code
        I doubt there's a lot of ancient perl4 code laying around. That's not the problem.

        It's the unknown quantities of code written in the last 15 years that will break if use strict; suddenly becomes the default. Note that includes oodles of code that runs without problems.

        And the amount of code will only grow.

        I'm sure you could convince p5p to make use strict; the default if you can show there's not much code out there that would break. But you don't know how much code is out there - and how it's written. Noone knows.

        And yes, I'm aware that this discussion won't change Perl5, and it's too late now to change Perl5 to have strict mode on by default. But at least we can learn this lesson for Perl6.
        Perl6 will have strict on by default. Or at least, it still had that last time I heard someone trying to get me the drink the Perl6 Kool-Aid. But who knows, it may have changed since.
        Modern::Perl is a pretty neat idea, but it is not a core module
        Wait? You don't mind if other people have to change their, currently working, code, but you find it a problem if a module that helps you write "modern" (for some value of "modern") code is a module that has to be downloaded from CPAN?

        With the new operators for 5.10, we see a very similar problem: Backwards compatibility at every cost, even if it makes writing modern Perl harder.
        Backwards compatibility is very important. And how are the "new operators" keeping you from writing "modern Perl"?

        Oh, and if you're so saffy you're writing "modern Perl", you'll be able to write an editor macro that puts "use strict;" in your files for you? I've no clue how to write "modern Perl", or even what it is, but I haven't had a need to type use strict; to get strictness for a long, long time. Two keystrokes, and it says "#!/usr/bin/perl\nuse strict;\nuse warnings;\n". A slight variations, and it does the same with a package statement instead of a she-bang line. I really do not buy the argument "my fingers are wearing out typing 'use strict'".

Re: use strict
by FunkyMonk (Chancellor) on Jan 26, 2010 at 15:59 UTC
    It will come "free" with use 5.11; onwards.

    From use in http://perl5.git.perl.org/perl.git/blob_plain/HEAD:/pod/perl5114delta.pod:

    Also, if the specified Perl version is greater than or equal to 5.9.5, "use VERSION" will also load the "feature" pragma and enable all features available in the requested version. See feature. Similarly, if the specified Perl version is greater than or equal to 5.11.0, strictures are enabled lexically as with "use strict" (except that the strict.pm file is not actually loaded).
Re: use strict
by wfsp (Abbot) on Jan 26, 2010 at 15:28 UTC
    Stop people hanging themselves? You want a nanny perl? :-)

    What effect would it have on one liners and golf? What about existing strictless scripts?

    You don’t have use it if you don’t want to and clearly many don’t for both good and bad reasons.

    I’ve seen code with it commented out in a desperate attempt to get some monster of a script to run and it always makes my heart sink (if they’re prepared to do that what other crimes have they committed?).

    I think I would be cautious about changing a significant default after 10 years.

Re: use strict
by chromatic (Archbishop) on Jan 26, 2010 at 18:50 UTC
    ... why can't "strict" mode be made the default?!?!

    Many core libraries will not work under and enforced strict, at least in 5.11.x. That's fixable, but it requires the will to do so.

    I talked to Jesse Vincent, and he's happy to accept patches that clean up core libraries for strictness (among other things), as long as their external interfaces do not change.

Re: use strict
by Jenda (Abbot) on Jan 26, 2010 at 16:58 UTC

    I was not using Perl in the old Perl4 times. I use strict in all my scripts for quite some time. But I would not want it to be default. It'd break my one-liners. And it's those I tend to type repeatedly, not the first four lines of the scripts (

    #!perl use strict; use warnings; no warnings 'uninitialized';
    )

    Besides most of the problems would not be solved. People would just blindly put my or our all over the place to silence the error messages and their variables would be just as global and their programs just as badly designed.

    Jenda
    Enoch was right!
    Enjoy the last years of Rome.

      It'd break my one-liners.
      Most suggestions to have it enabled by default make the exception for command line scripts (if -e or -E is used). AFAIK, Perl6 doesn't enable strict for command line scripts either.
Re: use strict
by SuicideJunkie (Vicar) on Jan 26, 2010 at 15:17 UTC

    As a rule of thumb, I would expect that if "use strict;\n" comprises less than about 5% of the file, it is worth using.

    In addition to legacy code, some of the rare places where you would avoid using strict include one-liners and golfing.

Re: use strict
by talexb (Chancellor) on Jan 28, 2010 at 18:56 UTC

    In maintenance programming, one of the first rules I can think of is "Make the smallest possible change that's going to fix the bug or add the feature." So adding something like use strict, while an excellent idea, may cause undesirable side effects, either the same warning messages appearing a thousand times an hour in the error log, or a failure to compile, resulting in the customer seeing an Internal Server Error. Sad face.

    I'm all for using strict when working on new development, but adding that to something in production needs to be used sparingly.

    Alex / talexb / Toronto

    Team website: Forex Chart Monkey, Forex Technical Analysis and Pickpocket Prevention

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

Re: use strict
by cdarke (Prior) on Jan 30, 2010 at 16:37 UTC
    "I disapprove of not using strict, but I will defend to the death your right not to use it."

    A difference between Perl and other languages is choice in how we write and use it. Vive la différence!
Re: use strict
by Anonymous Monk on Jan 26, 2010 at 16:07 UTC
Re: use strict
by Anonymous Monk on Jan 26, 2010 at 15:40 UTC
    set PERL5OPT=-MModern::Perl or exportPERL5OPT=-MModern::Perl or echo use Modern::Perl; >> $Config{sitelib}/sitecustomize.pl
    Modern::Perl
Re: use strict
by matze77 (Friar) on Jan 29, 2010 at 06:55 UTC
    Use strict will break code, if you simply enable it afterwards.
    So I think it is the right decision not to do this (Enable it by default).
    I think let people decide what they do even if it is probably "Not the right way or Best Practice". Thats freedom ...
    I think it is useful to use strict, but it should be used from the first line of code not enabled afterwards otherwise it will break the program almost for sure (At least it does with my simple pieces of code this wont be better with large programs?) ...