我最近从CPAN安装了一个模块,并注意到它的一个依赖项是常见的:: sense,一个模块,它提供了你想要的所有警告,没有你不需要的.从模块的概要:
use common::sense;
# supposed to be the same, with much lower memory usage, as:
#
# use strict qw(vars subs);
# use feature qw(say state switch);
# no warnings;
# use warnings qw(FATAL closed threads internal debugging pack substr malloc
# unopened portable prototype inplace io pipe unpack regexp
# deprecated exiting glob digit printf utf8 layer
# reserved parenthesis taint closure semicolon);
# no warnings qw(exec newline);
除了undef警告有时候很麻烦,我通常会发现标准警告是好的.是否值得转换common::sense而不是我的正常use strict; use warnings;？
dao*_*oad 24
虽然我喜欢减少样板代码的想法,但我对Modern :: Perl和common :: sense等工具深感怀疑.
我对这些模块的问题在于它们捆绑了一组行为并隐藏了具有可变含义的behid glib名称.
例如,Modern::Perl今天包括启用一些perl 5.10功能并使用严格和警告.但是当Perl 5.12或5.14或5.24带来了很多新的好东西时会发生什么,并且社区发现我们需要在frobnitz任何地方使用pragma？将Modern :: Perl提供一系列一致的行为,还是保持"现代".如果MP与时间保持一致,它将破坏不与其编译器要求保持锁定步骤的现有系统.它增加了额外的兼容性测试以升级.至少那是我对议员的反应.我是第一个承认色彩比我聪明10倍的人,也是一个更好的程序员 - 但我仍然不同意他对这个问题的判断.
common::sense也有名字问题.涉及谁的常识的想法？它会随着时间而改变吗？
我倾向于使用一个模块,使我可以轻松创建自己的标准模块集,甚至为特定任务创建相关模块/编译指示组(如日期时间操作,数据库交互,html解析等).
我喜欢Toolkit的想法,但它有两个原因:它使用源过滤器,宏系统过于复杂和脆弱.我非常尊重达米安康威,并且他制作了出色的代码,但有时他会走得太远(至少在生产中使用,实验很好).
我没有输入足够的时间use strict; use warnings;来感觉需要创建我自己的标准导入模块.如果我觉得强烈需要自动加载一组模块/编译指示,那么类似于Toolkit的东西可以创建标准功能组,这是理想的:
use My::Tools qw( standard datetime SQLite );
要么
use My::Tools;
use My::Tools::DateTime;
use My::Tools::SQLite;
工具包非常接近我的理想.它的致命缺陷令人失望.
至于pragma的选择是否有意义,这是一个品味问题.我宁愿偶尔no strict 'foo'或no warnings 'bar'在一个块中使用我需要能力做一些需要它的东西,而不是禁用对整个文件的检查.另外,IMO,内存消耗是一个红色的鲱鱼.因人而异.
更新
似乎有很多(多少？)这种类型的不同模块漂浮在CPAN周围.
Toolkit能力,但没有源过滤器.strict,并warnings给调用包.这些模块的激增以及需求重叠的可能性增加了另一个问题.
如果您编写如下代码会发生什么:
use Moose;
use common::sense;
哪些pragma启用了什么选项？
Tel*_*hus 15
我会说坚持warnings并且strict主要有两个原因.
warnings和strict与他们的规则.这些代表了您和您合作的其他人可以信赖的社区规范.warnings和strict或一个地方我槎到common::sense？" 在两种模式之间来回移动会让您感到困惑.Ken*_*ric 15
似乎没有其他人接受过,这就FATAL在warnings列表中.
从2.0开始,use common::sense更类似于:
use strict;
use warnings FATAL => 'all'; # but with the specific list of fatals instead of 'all' that is
这是一个有点重要且经常被忽视的警告特征,它将严格程度提高了一个整体.而不是undef字符串插值,或无限递归只是警告你,然后尽管问题继续前进,它实际上停止.
对我来说这很有用,因为在很多情况下,undef字符串插值会导致更多危险的错误,这些错误可能会被忽视,而失败和失败是一件好事.
我显然没有常识,因为我更多的是为了Modern::Perl ;-)
该"更低的内存使用率"只有当你使用的作品没有模块加载严格,特征,警告等与"多"的部分是......不是所有的东西.
不是每个人对常识的看法都是一样的 - 在这方面它不是常见的.
跟你所知道的去吧.如果收到undef警告,则可能是您的程序或其输入不正确.
警告是有原因的.任何减少它们的东西都无济于事.(我总是编译gcc -Wall...)
在我的代码中,我从未收到任何狡猾/完全错误的警告.对我来说,技术上总是允许的,我几乎肯定不想做.我认为全套警告非常宝贵.如果你现在发现use strict+ use warnings足够了,我不明白你为什么要改用一个非标准模块,这个模块就是你从这里开始编写的每一段代码的依赖...