Question

我最近从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;？

Answer 1

虽然我喜欢减少样板代码的想法，但我对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;来感觉需要创建我自己的标准导入模块。如果我觉得强烈需要自动加载一组模块/ pragma，那么类似于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，内存消耗是一个红色的鲱鱼。 YMMV。

<强>更新

似乎有很多（多少？）这种类型的不同模块在CPAN周围浮动。

有latest，不再是最新版本。演示部分命名问题。
此外，uni::perl添加了混合的启用unicode部分。
ToolSet提供了Toolkit能力的子集，但没有源过滤器。
我会在此处添加Moose，因为它会自动将strict和warnings添加到调用包中。
最后Acme::Very::Modern::Perl

这些模块的激增以及需求重叠的可能性增加了另一个问题。

如果您编写如下代码会发生什么：

use Moose;
use common::sense;

使用哪些选项启用了哪些编译指示？

Answer 2

我认为坚持warnings和strict主要有两个原因。

如果其他人要使用或使用您的代码，他们（几乎可以肯定）习惯warnings和strict及其规则。这些代表了您和您合作的其他人可以信赖的社区规范。
即使这个或特定的代码片段只适合您，您可能也不想担心记住“这是我遵守的项目吗？ warnings和strict或我{1 common::sense的那个？在两种模式之间来回移动会让你感到困惑。

Answer 3

在FATAL列表中，似乎没有其他人接受，warnings列表中的use common::sense。

从2.0开始，use strict; use warnings FATAL => 'all'; # but with the specific list of fatals instead of 'all' that is更类似于：

{{1}}

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

对我来说这很有用，因为在很多情况下，undef字符串插值会导致更多危险的错误，这些错误可能会被忽视，而失败和捞取是一件好事。

Answer 4

我显然没有常识，因为我为Modern::Perl做了更多; - ）

Answer 5

“较低的内存使用率”仅在您使用 no 模块加载严格，功能，警告等时才有效，并且“很多”部分......不是那么多。

Answer 6

并非每个人对常识的看法都是一样的 - 在这方面它不是常见的。

跟你所知道的去吧。如果您收到undef警告，则可能是您的程序或其输入不正确。

警告是有原因的。任何减少它们的东西都无济于事。（我总是用gcc -Wall编译......）

Answer 7

我的代码中从来没有发出任何狡猾/完全错误的警告。对我来说，技术上总是允许的，我几乎肯定不想做。我认为全套警告非常宝贵。如果您现在发现use strict + use warnings已足够，我不明白为什么您要更改为使用非标准模块，然后该模块是您编写的每段代码的依赖项在这里...

Answer 8

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

但如果您对标准警告感到满意，请坚持下去。如果你已经习惯了，编码到更严格的标准是很好的！我不建议只为节省内存而切换。只有在模块可以帮助您更快，更自信地转动代码时才能切换。

Answer 9

许多人在与的评论中争辩说如果MP改变了，它将破坏你的代码。虽然这可能是一个真正的威胁，但这已经很多事情随着时间的推移会发生变化并破坏代码（有时在弃用周期之后，有时候不会......）。

其他一些模块改变了API，因此打破了事情，没有人关心它们。例如。 Moose至少有两件现在被弃用的东西，在未来的某些版本中可能会被禁止。

另一个例子，多年前被允许写

for $i qw(some words)

现在，它已被弃用。还有很多其他......这是一种CORE语言语法。

每个人都活了下来。所以，不要真正理解为什么许多人争论再次帮助模块。当他们要改变时，（可能）这里将是一种弃用周期 ...所以，我的观点是：

如果您自己编写程序，请使用您想要的任何模块;）
如果你给别人写一个程序，其他人去做其他人，请使用最少的非标准＆＃34; pragma-like＆＃34;模块（common :: sense，modern :: perl，uni :: perl等...）
在stackoverflow问题中，您可以安全地使用common::sense或Modern::Perl等 - 将回答的大多数用户都知道他们。每个人都明白，使用10个字符编写use 5.010;表示启用strict, warnings and fearures比使用3行更容易...

我应该使用common :: sense还是坚持使用`use strict`和`use warnings`？

9 个答案: