Question

我订阅了beginners@perl.org 正在进行讨论，一个人建议你不要使用

#!/usr/bin/perl -w

这将打开完整程序的警告。他说：

请不要在hashbang中使用-w，它强制使用   警告无处不在，即使模块不想要警告。你会   如果你把它留下来会得到奇怪的错误信息。相反，只需写下“使用   警告;“在你的代码的顶部，你会没事的。：）

它会激活您未编写的代码的警告。

为您编写的所有代码启用警告是一个非常好的主意   你自己。但是，如果您为由作者编写的代码启用它   不想要警告，或者对于旧模块，那么你将变得毫无意义   你无法修复的消息。

我说：所以你想说我们应该只在某些方面使用警告   部分代码。

他回答说：是的，具体来说：只有你自己编写的代码。

而不是这样做，你应该在自己编写的代码中使用warnings pragma而不是完整的程序。

我曾经在shebang写过-w，这样我就可以打开完整程序的警告。但在讨论之后，我很困惑我是否应该跟随那个人。他是对的吗？我们应该避免为完整的程序打开警告吗？

通常我遵循的是

#!/usr/bin/perl
use strict;
use warnings;

#now start actual coding from here
#...............................
#...............................

Answer 1

你已经相当准确地描述了这种情况。 -w全局打开警告（在所有模块中，除非它们特别在词汇上关闭它们）。 use warnings表现出词汇，不会影响其他模块中发生的事情。

话虽如此，我不认为这是一个更好的问题。这真的是你想要的行为。在不知道断言的上下文的情况下，我们不会说foreach优于while。如果您希望通过各种方式在全球范围内启用警告，请执行此操作。如果要以不影响外部模块的方式打开警告，请执行此操作。

在我看来，警告是一种开发和调试工具。我尝试总是用'on'（在我自己的代码中）警告编程。我是否在启用警告的情况下将代码部署到生产中是另一回事。有许多因素有助于决定是否应在生产代码中启用警告。当然，目标是无警告。因此，如果在生产代码中启用了警告，并且只有一个消失，那么如果我们正确地完成工作，就不会发生这种警告。但如果一个人漏掉了，这些信息对任何人都有帮助吗？并且有用性是否会超过增加的噪音和将程序信息暴露给未知最终用户的潜在风险？

关于编写无警告代码的主题：是的，这应该始终是目标。但是有很多警告。 my @list = qw/ Just another Perl hacker, /;会触发警告。这个警告旨在帮助我意识到我可能犯了一个错误（在qw //列表中嵌入一个逗号）。但正如许多人所知，该短语以逗号结尾。这里更大的问题是我是否真的打算列出单词而不是单个字符串。所以我要说我确实需要一个单词列表，并且一个单词在其末尾合法地需要一个逗号。在这种情况下，警告是轻浮的。我有两个选择。一个，比如my ( @list ) = ( 'Just', 'another', 'Perl', 'hacker,' );或两个，说my ( @list ) = do{ no warnings 'qw'; qw/Just another Perl hacker,/; };。它们都是很多打字，在这个人为的例子中，最好只是咬紧牙关并使用第一个选项。但这并不意味着第二种选择是错误的，并且可能有许多设计较少的例子表明警告不合适。

现在让我们看看在另一个模块中触发警告可能有用的情况：你一直在撕扯你为什么没有从XYZ模块获得预期结果。你可以使用print语句来编写你的代码，你可以转储你的数据结构，你可以深入到Perl调试器......但是在全局启用警告有什么问题，如果只是为了一次运行，看看你正在做的事情是否会产生问题在远处，模块内的无声故障？显然，如果你把垃圾送到垃圾桶里，一个写得很好的模块会给你带来麻烦。但是应该/会......这取决于该模块的作者。你的最大方面是，你可以提升到警告之前可能是无声失败的事情。鉴于它是一个如此简单的调试步骤，在使用调试器逐步执行代码之前可能值得一试。

您已经发现了这一点，但为了其他读者，perllexwarn讨论了-w，使用警告和$ ^ W之间的区别。

Answer 2

Quoth the documentation：

BUGS

-w 开关不是强制性的。

使用-w。任何在启用-w时发出“奇怪警告”的模块编码都很差，应该避免使用，并且应该升级旧模块。

Answer 3

使用-w或明确use warnings;打开警告，直到它导致您与其他人的模块出现问题。并不是因为他面临着大多数人都不会遇到的异常情况，所以这个人并非如此。

当模块确实发出无法修复的警告时，请考虑在加载该模块时有选择地禁用警告 - 但考虑是否有更好的替代模块没有警告。在过去的几年里，我没有碰到许多模块的问题;我从来不需要有选择地使用警告。我安装了很多模块（虽然我使用的模块少于我应该使用的模块）。

Answer 4

我是最初提出他提到的评论的人，我特意想到这类模块：

它们中的大多数都是很棒的工具，可以做出奇怪的事情并有充分的理由避免警告。特别是事件循环，其中性能是关键。

现在，请记住我在初学者邮件列表中说过这个。我的建议针对那些几乎无法调试自己代码的人。让他们在全球范围内启用警告，在他们没有编写的代码中，不控制并且通常甚至不理解只是在寻找麻烦。通常他们甚至不会理解（或记住）他们为什么会收到这些警告。

-w只应在您完全了解它的用途时使用。

我们应该避免为完整的程序打开警告吗？

4 个答案:

BUGS