我应该使用 common::sense 还是坚持使用“use strict"和“use warnings"? [英] Should I use common::sense or just stick with `use strict` and `use warnings`?

问题描述

我最近从 CPAN 安装了一个模块，并注意到它的一个依赖项是 common::sense，一个模块，提供您想要的所有警告，而没有您不想要的警告.来自模块的概要:

I recently installed a module from CPAN and noticed one of its dependencies was common::sense, a module that offers to enable all the warnings you want, and none that you don't. From the module's synopsis:

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;使用警告；?

Save for undef warnings sometimes being a hassle, I've usually found the standard warnings to be good. Is it worth switching to common::sense instead of my normal use strict; use warnings;?

推荐答案

虽然我喜欢减少样板代码的想法，但我对 Modern::Perl 和 common::sense 等工具深表怀疑.

While I like the idea of reducing boiler-plate code, I am deeply suspicious of tools like Modern::Perl and common::sense.

我在使用此类模块时遇到的问题是，它们将一组行为捆绑在一起，并隐藏了含义可变的 behid glib 名称.

The problem I have with modules like this is that they bundle up a group of behaviors and hide behid glib names with changeable meanings.

例如，今天的 Modern::Perl 包括启用某些 perl 5.10 功能并使用严格和警告.但是，当 Perl 5.12 或 5.14 或 5.24 推出新的好东西，并且社区发现我们需要在任何地方使用 frobnitz pragma 时会发生什么?Modern::Perl 将提供一组一致的行为还是将保持现代".如果 MP 与时俱进，它将打破现有系统，这些系统不与其编译器要求保持同步.它增加了额外的兼容性测试来升级.至少这是我对 MP 的反应.我会第一个承认 chrom 比我聪明 10 倍，而且还是一个更好的程序员——但我仍然不同意他在这个问题上的判断.

For example, Modern::Perl today consists of enabling some perl 5.10 features and using strict and warnings. But what happens when Perl 5.12 or 5.14 or 5.24 come out with great new goodies, and the community discovers that we need to use the frobnitz pragma everywhere? Will Modern::Perl provide a consistent set of behaviors or will it remain "Modern". If MP keeps with the times, it will break existing systems that don't keep lock-step with its compiler requirements. It adds extra compatibility testing to upgrade. At least that's my reaction to MP. I'll be the first to admit that chromatic is about 10 times smarter than me and a better programmer as well--but I still disagree with his judgment on this issue.

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

common::sense has a name problem, too. Whose idea of common sense is involved? Will it change over time?

我更喜欢一个模块，它使我可以轻松创建自己的标准模块集，甚至可以为特定任务(如日期时间操作、数据库交互、html 解析等)创建相关模块/编译指示组).

My preference would be for a module that makes it easy for me to create my own set of standard modules, and even create groups of related modules/pragmas for specific tasks (like date time manipulation, database interaction, html parsing, etc).

我喜欢 Toolkit 的想法，但它很糟糕有几个原因:它使用源过滤器，而且宏观系统过于复杂和脆弱.我非常尊重 Damian Conway，他编写了出色的代码，但有时他走得太远了(至少对于生产用途而言，实验是好的).

I like the idea of Toolkit, but it sucks for several reasons: it uses source filters, and the macro system is overly complex and fragile. I have the utmost respect for Damian Conway, and he produces brilliant code, but sometimes he goes a bit too far (at least for production use, experimentation is good).

我没有浪费足够的时间输入 use strict;使用警告； 感觉需要创建我自己的标准导入模块.如果我强烈需要自动加载一组模块/编译指示，那么类似于 Toolkit 的东西，它允许创建标准功能组将是理想的:

I haven't lost enough time typing use strict; use warnings; to feel the need to create my own standard import module. If I felt a strong need for automatically loading a set of modules/pragmas, something similar to Toolkit that allows one to create standard feature groups would be ideal:

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

或

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

Toolkit 非常接近我的理想.它的致命缺陷令人失望.

Toolkit comes very close to my ideal. Its fatal defects are a bummer.

至于选择 pragma 是否有意义，这是一个品味问题.我宁愿偶尔使用 no strict 'foo' 或 no warnings 'bar' 在我需要能够做一些需要它的事情的块中，而不是禁用检查我的整个文件.另外，IMO，内存消耗是一个红鲱鱼.天啊.

As for whether the choice of pragmas makes sense, that's a matter of taste. I'd rather use the occasional no strict 'foo' or no warnings 'bar' in a block where I need the ability to do something that requires it, than disable the checks over my entire file. Plus, IMO, memory consumption is a red herring. YMMV.

更新

似乎有很多(有多少?)这种类型的不同模块围绕着 CPAN 浮动.

It seems that there are many (how many?) different modules of this type floating around CPAN.

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

• There is latest, which is no longer the latest. Demonstrates part of the naming problem.
• Also, uni::perl which adds enabling unicode part of the mix.
• ToolSet offers a subset of Toolkit's abilities, but without source filters.
• I'll include Moose here, since it automatically adds strict and warnings to the calling package.
• And finally Acme::Very::Modern::Perl

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

The proliferation of these modules and the potential for overlapping requirements, adds another issue.

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

What happens if you write code like:

use Moose;
use common::sense;

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

What pragmas are enabled with what options?

这篇关于我应该使用 common::sense 还是坚持使用“use strict"和“use warnings"?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！