代码之家 › 专栏 › 技术社区 › Drew Stephens

我应该使用common::sense还是只使用'use strict'和'use warnings'?

perl

Drew Stephens · 技术社区 · 15 年前

我最近安装了一个来自CPAN的模块,发现它的一个依赖项是 common::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; ?

9 回复 | 直到 8 年前

daotoad 15 年前

虽然我喜欢减少锅炉板代码的想法,但我对诸如modern::perl和common::sense之类的工具有着深深的怀疑。

我对类似这样的模块的问题是,它们捆绑了一组行为,隐藏了含义可变的behid glib名称。

例如, Modern::Perl 今天,我们将启用一些Perl5.10特性,并使用严格和警告。但是,当Perl5.12、5.14或5.24出现新的好东西,并且社区发现我们需要使用 frobnitz pragma无处不在?Perl将提供一组一致的行为,还是将保持“现代”。如果MP与时俱进,它将破坏现有系统,这些系统不符合编译器的要求。它增加了额外的兼容性测试来升级。至少这是我对议员的反应。我将是第一个承认彩色比我聪明10倍,也是一个更好的程序员——但我仍然不同意他对这个问题的判断。

common::sense 也有名字问题。涉及到谁的常识?它会随着时间而改变吗?

我的首选是一个模块,它使我可以轻松地创建自己的一组标准模块,甚至可以为特定任务(如日期时间操作、数据库交互、HTML解析等)创建相关模块/pragma组。

我喜欢 Toolkit 但它之所以糟糕,有几个原因:它使用了源过滤器,而且宏系统过于复杂和脆弱。我非常尊重Damian Conway,他编写了出色的代码,但有时他做得太过分了(至少在生产使用中,实验是好的)。

我没有浪费足够的时间打字 use strict; use warnings; 感觉需要创建自己的标准导入模块。如果我觉得非常需要自动加载一组模块/pragma,那么类似于工具包的东西(允许创建标准功能组)将是理想的:

use My::Tools qw( standard datetime SQLite );

或

use My::Tools;
use My::Tools::DateTime;
use My::Tools::SQLite;

工具箱非常接近我的理想。它致命的缺陷是一个令人不安的。

至于语用的选择是否合理,这是一个品味问题。我宁愿偶尔使用 no strict 'foo' 或 no warnings 'bar' 在一个块中,我需要能够做一些需要它的事情,而不是禁用对整个文件的检查。另外,在我看来,记忆的消耗是一条红鲱鱼。YMMV。

更新

似乎有很多(多少?)这种类型的不同模块在CPAN周围浮动。

有 latest 不再是最新的。演示命名问题的一部分。
也, uni::perl 这增加了组合中启用Unicode的部分。
ToolSet 提供的子集 Toolkit 的能力,但没有源过滤器。
我会包括 Moose 这里,因为它会自动添加 strict 和 warnings 到呼叫包。
最后 Acme::Very::Modern::Perl

这些模块的扩散和重叠需求的可能性增加了另一个问题。

如果您编写的代码如下:

use Moose;
use common::sense;

用什么选项启用了什么pragma?

Telemachus MrJames 15 年前

我会说坚持 warnings 和 strict 主要有两个原因。

如果其他人打算使用或使用您的代码,他们(几乎可以肯定)习惯于 警告 和 严格的 以及他们的规则。这些都代表了你和你的同事可以信赖的社区规范。
即使这或那个特定的代码只是为您准备的,您可能不想担心记住“这是我坚持的项目吗?” 警告 和 严格的 或者我要去的地方 common::sense ?“在两种模式之间来回移动只会让你困惑。

Kent Fredric 15 年前

有一点似乎没人注意到,那就是 FATAL 在 warnings 名单。

截至2, use common::sense 更类似于:

use strict; 
use warnings FATAL => 'all'; # but with the specific list of fatals instead of 'all' that is

这是一个有点重要而且经常被忽视的警告特征,它将严格程度提高了一个整体。它实际上停止了,而不是取消定义字符串插值,或者无限递归只是警告您,然后继续执行,尽管有问题。

对我来说,这是有帮助的,因为在许多情况下,UNdef字符串插值会导致更危险的错误,这些错误可能会悄悄地被忽略,失败和回收是一件好事。

AndyG 8 年前

我显然没有常识,因为我更愿意 Modern::Perl ;-)

ysth 15 年前

只有当您使用不加载严格、功能、警告等的模块,“多”部分是……不多。

Alnitak 15 年前

并不是每个人的常识都是一样的——在这方面,它只是普通的。

随遇而安。如果你得到 undef 警告,您的程序或其输入可能不正确。

警告是有原因的。任何减少它们的方法都是无用的。(我总是用 gcc -Wall 太……)

ire_and_curses 15 年前

我从来没有收到过一个警告,在我的代码中没有什么不可靠/只是明显的错误。对我来说,技术上总是允许我不想做的事情。我认为全套警告是无价的。如果你发现 use strict + use warnings 现在就足够了,我不明白您为什么要改为使用非标准模块,而非标准模块则是您从这里开始编写的每一段代码的依赖项。

joealba 15 年前

当涉及到警告时,我支持使用任何模块或内置语言功能,这些功能为您提供警告级别,帮助您使代码尽可能地可靠和可靠。忽略的警告对任何人都没有帮助。

但是如果你对标准的警告感到舒适,那就坚持下去。如果你习惯了,用更严格的标准编码是很好的!我不建议仅仅为了节省内存而切换。只有在模块帮助您更快、更自信地转换代码时才进行转换。

clt60 11 年前

许多人在评论中争论 如果MP更改,它将破坏您的代码 . 虽然这可能是一个真正的威胁,但这里已经有很多事情是随着时间的推移而改变的,并且破坏了代码(有时是在一个折旧周期之后,有时不是…)。

其他一些模块改变了API,所以破坏了一些东西,没有人关心它们。例如。 Moose 至少有两件事现在被否决了,可能在将来的一些版本中将被禁止。

另一个例子,几年前被允许写

for $i qw(some words)

现在,它被弃用了。还有很多其他的…这是一个核心语言语法。

所有人都活了下来。所以,不要真的理解为什么很多人会争论Againist帮助模块。当他们要改变的时候,(可能)这里会有一种 折旧周期 ……所以,我的观点是:

如果您自己编写程序,请使用所需的任何模块;)
如果您向某人编写一个程序,而其他人要在其中维护它,请使用最小的非标准“类pragma”模块(common::sense、modern::perl、uni::perl等…)
在stackoverflow问题中,您可以安全地使用 common::sense 或 Modern::Perl 等等-大多数用户 会回答的,你的问题 认识他们。人人都明白,写起来容易。 use 5.010; 为使能 strict, warnings and fearures 有10个字符,有3行…