为什么不在Perl中使用严格和警告?

我已经看到模糊的和高尔夫球的代码保持不变,以避免声明变量,我可以看到在命令行上使用-e开关跳过它们以保持单行程更短.在某些情况下,您不希望在生产代码中使用严格和/或使用警告?什么是不想使用它们的原因?

问题出现了,因为我在这里看到有经验的Perl用户告诉那些Perl新手一直使用它们的帖子.

在这里找到了一些相关的问题,但他们并没有解释我们可能希望将其关闭的情况.

解决方法

严格的pragma限制你到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})上生效.

相关文章

1. 如何去重 #!/usr/bin/perl use strict; my %hash; while(...
最近写了一个perl脚本,实现的功能是将表格中其中两列的数据...
表的数据字典格式如下:如果手动写MySQL建表语句,确认麻烦,...
巡检类工作经常会出具日报,最近在原有日报的基础上又新增了...
在实际生产环境中,常常需要从后台日志中截取报文,报文的形...
最近写的一个perl程序,通过关键词匹配统计其出现的频率,让...