Using strict is hard, let's just use Moose;
I've been running into more and more code which uses Moose, and doesn't use strict. The logic being that since Moose uses strict, your code doesn't need to.
Is there something about Moose's use of strict that differs from other modules that use strict? Say for instance that if I use Carp in my code (which uses strict), is it still ok not to use strict?
What worries me as someone who works on legacy systems where code doesn't use strict, is that best practices are de-evolving. New Perl programmers will see code that uses Moose but not strict, and go on to write programs that don't use Moose and also don't use strict. It makes me wonder if the practices that are being implemented in Modern Perl for the benefit of experienced users will set bad precedents for inexperienced users.
Hey 5.16 developers, can you enable strictures and warnings by default? Now that makes sense to me.
I blog about Perl.
The reason people who use Moose do not also use strict/warning is because Moose->import (which is called when you use Moose) will import strict and warning into your namespace, thus you do not need to manually use them. This will demonstrate the effect:
package stuff; use strict; use warnings; sub import { strict->import; warnings->import; }package main;
no strict; no warnings;
BEGIN { stuff->import; } # Emulation of "use stuff"
print $c;
As you can see, strict is in effect during the print even though strict was turned off. You can see this with Moose as well:
Ah there it is. Thanks for the spot.
lib/Moose/Exporter.pm:410: strict->import;
lib/Moose/Exporter.pm:644: strict->import;
But I do agree with you that the lack of seeing "use strict" in Moose-using code may perhaps lead people to not use strict when they are not using a package that imports strict into your namespace. Personally even when I use Moose, I also add the strict and warnings lines as well.
> Hey 5.16 developers, can you enable strictures and warnings by default? Now that makes sense to me.
That's been already the case since 5.12, but only when you declare 'use v5.12' (or v5.14 etc.).
% perl -e 'use v5.12; $x'Global symbol "$x" requires explicit package name at -e line 1.
If the upgraded perl enables strict *everywhere* then all the existing program that has no 'use strict' will break, and that's terrible.
I'm aware of the 'use v5.12' feature for turning on strictures by default, but I have some fear of committing to a specific version when newer versions are now being regularly released.
It would be bad to break legacy code when upgrading to a newer version of perl, but in my own experience I tend to see others writing new code which doesn't use strict, and then I have to spend time fixing their code when they ask me why it doesn't work.
I am starting to experience cases of needing to update code because newer versions of perl throw deprecation warnings for stuff like qw() used as parentheses. That has stood out in my mind as a success in the upgrade process; the code still works, but nudges you in the right direction.
You may feel better if you've seen Jesse Vincent's talk about the future of Perl 5. The basic gist is if you declare a version, Perl will try it's hardest to keep to the semantics of that version. The defaults without declaring a version should be (if all goes according to plan) what you currently get with Perl 5.14.x when you don't declare a version.
As for the people writing new code without strict. Only education can help. (well, of course unless you want to shoot them but that's messy). So every time they come to you treat it as an opportunity to to show them how use strict will help them. You can mention saved time, or saved sanity or safety belts. Whatever might work for them.
Maybe eve try to start a code review process where they will show their code to you even before they bump into a problem.
Education works sometimes, but I still know of at least one programmer (with several years experience) who starts code without strict.
I've been thinking about this more - like @miyagawa said, enabling strict by default could cause problems with legacy code. However, it might make sense to provide compile time options to enable strict and warnings by default (or not by default). Maybe that's something I'll proposed to p5p.