问题出现了,因为我在这里看到有经验的Perl用户告诉那些Perl新手一直使用它们的帖子.
我在这里找到了一些相关的问题,但他们并没有解释我们可能希望将其关闭的情况.
解决方法
严格的pragma有三类：
>“vars”强制你声明所有的变量.这屏蔽了打字错误,并确保您选择范围(全局/词法).在一个单行中,这不是很需要的,因为通常很少的范围和很少的变量.一些单行习语只适用于词汇变量.
>“refs”不允许symrefs.他们对词汇变量没有意义,Perl5有真正的参考.所以他们一般是没用的.然而,symrefs对于元编程仍然是有价值的：
# generate accessors
for my $field (qw/foo bar baz/) {
no strict 'refs';
*{ __PACKAGE__ . '::' . $field } = sub { shift()->{$field} };
}
>“subs”强制将大多数裸术的解释作为子程序调用.这解决了foo的模糊性. “bar”为foo(). “酒吧”.如果此类别未激活,并且如果当前没有定义foo sub,那么它将被解析为“foo”. “酒吧”.这对一个shell程序员来说是有意义的,所有的单词都是字符串.但是在Perl程序中,这大大增加了程序员的认知负担,并不值得.
总结：对于不优化可读性的简单脚本,严格的“vars”并不是非常必要的.有几种情况下,不需要严格的“参考”.
警告pragma允许对警告消息进行细粒度控制.这对于Perl的程序员来说尤其重要,Perl经常写这样的东西
my %hash = { foo => 1,bar => 2 };
并想知道HASH(0x1234567)的密钥来自哪里.即使在一个班轮上,警告也是可取的,除非你使用undef等的字符串
在专业的代码库中,没有任何借口无法在任何地方使用警告.如果一个脚本警告,这很可能是一个错误,没有任何警告不会使这个错误消失.你对Perl的了解绝对不会像警告语一样粗糙.甚至大师也犯错误.使用警告是一个很好的调试快捷方式.
也就是说,在部署程序时可能会对使用警告进行评论.但永远不会发展.
根据开发团队的共识,还应该使用其他的pragmas：
>没有间接禁止不幸的新的Foo方法调用.我已经看到错误潜入,可能在编译时被抓住了这个编译.> no autovivification可以防止引用在只读操作(如$hash {doesnt_exist} {foo})上生效.