我见过一些混淆和打高尔夫球的代码，这些代码保持关闭状态以避免声明变量，并且我可以看到使用 -e 开关在命令行上跳过它们以保持单行更短。在哪些情况下您不希望这样做use strict and/or use warnings在生产代码中？您不想使用它们的原因是什么？
之所以出现这个问题，是因为我在这里看到过一些帖子，经验丰富的 Perl 用户告诉 Perl 新手：always使用它们。
我确实在这里找到了一些相关的问题，但它们没有解释我们可能想要关闭它们的情况。
The strictpragma 将您限制为 Perl 的一个合理的子集。一些旧功能具有历史意义（或者对单行代码有好处），但在现代、可读的代码库中没有位置。
The strictpragma 分为三类：
"vars"强制您声明所有变量。这可以防止拼写错误，并确保您选择一个范围（全局/词法）。在单行代码中，这并不需要那么多，因为通常作用域和变量都很少。一些单行习语不能只与词汇变量一起使用。
-
"refs"不允许使用 symref。它们对于词法变量没有任何意义，而 Perl5 有真正的引用。所以它们一般来说是没有用的。然而，符号引用对于元编程仍然很有价值：
# generate accessors
for my $field (qw/foo bar baz/) {
no strict 'refs';
*{ __PACKAGE__ . '::' . $field } = sub { shift()->{$field} };
}
"subs"强制将大多数裸字解释为子例程调用。这解决了歧义foo . "bar" to be foo() . "bar"。如果该类别未被激活，并且如果没有foosub 当前已定义，那么它将被解析为"foo" . "bar"。这对于 shell 程序员来说是有意义的，因为所有裸字都是字符串。但在 Perl 程序中，这极大地增加了程序员的认知负担，并且是不值得的。
摘要：对于未优化可读性的简单脚本，strict "vars"并不是真的有必要。有几种情况no strict 'refs'是所期望的。
The warningspragma 允许对警告消息进行细粒度控制。这对于刚接触 Perl 的程序员来说尤其重要，他们经常编写诸如
my %hash = { foo => 1, bar => 2 };
想知道那在哪里HASH(0x1234567)钥匙来自。即使在一行中，警告也是可取的，除非您使用字符串化undef etc.
在专业的代码库中，没有理由不使用warnings 到处。如果脚本发出警告，则很可能存在错误，并且no warnings不会让这个错误消失。你对 Perl 的了解永远不会像对 Perl 的了解那么广博。warnings杂注。即使是大师也会犯错误。use warnings是一个很好的调试快捷方式。
也就是说，评论一下可能没问题use warnings部署程序时。但绝不是为了发展。
根据开发团队的共识，还应该使用其他编译指示：
-
no indirect不允许被厌恶的人new Foo方法调用。我见过潜入的 bug，这些 bug 可能在编译时用这个 pragma 捕获。
-
no autovivification防止在只读操作中出现引用，例如$hash{doesnt_exist}{foo}.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
