你在Perl使用哪个安全网？ [英] Which safety net do you use in Perl?

问题描述

您使用哪个安全网？

使用警告;

use warnings;

或

使用strict;

use strict;

我知道

使用
strict捕获的潜在问题;将导致您的代码立即停止
遇到时，
同时使用警告;只会给出
警告（像命令行开关
-w），并让您的代码运行。

A potential problem caught by use strict; will cause your code to stop immediately when it is encountered, while use warnings; will merely give a warning (like the command-line switch -w) and let your code run.

仍然我想知道哪一个主要由Perl程序员使用。

Still I want to know that which one is mostly used by the Perl-programmers. Which one they have seen being used the most?

推荐答案

use strict 如果使用符号引用（即，字符串表示符号的名称），则会生成错误。如果你使用一个变量而不声明它，这会产生一个错误（这鼓励使用词法 my 变量，但是如果你正确地声明包全局变量也是如此）。如果你在脚本中留下裸字（无引号字符串，本质上是由Perl定义的引号），它也会产生一个错误。使用' strict '，您可以启用或禁用三种类型的狭窄，我在区域范围内这样做。这是一个最佳实践，启用狭窄，虽然偶尔合法的代码要求其某些功能在本地禁用。然而，我们应该仔细考虑这是否真的必要，以及他们的解决方案是否理想。您可以阅读Perl的POD中有关strict的详细信息。

use strict generates an error if you use symbolic references (ie, strings to represent names of symbols). It generates an error if you use a variable without declaring it (this encourages the use of lexical 'my' variables, but is also satisfied if you properly declare package globals). It also generates an error if you leave barewords hanging around in the script (unquoted strings, essentially, by Perl's definition of quotes). With 'strict', you may enable or disable any of three categories of strictures, and my do so within scoped blocks. It is a best practice to enable strictures, though on occasion legitimate code requires that some of its features be locally disabled. However, one should think long and hard about whether this is really necessary, and whether their solution is ideal. You can read about strictures in Perl's POD entitled 'strict'.

使用警告标准，其在POD'perllexwarn'中描述。这些警告与狭窄无关，而是注意在他们的编程中可能遇到的最常见的陷阱。这是一个最佳实践，在编写脚本时使用警告。在消息可能不合需要的某些情况下，某个警告类别可以在范围内被本地禁用。 警告中描述了其他信息。

use warnings generates a warning message based on many criteria, which are described in the POD 'perllexwarn'. These warnings have nothing to do with strictures, but rather, watch for the most common "gotchas" one is likely to encounter in their programming. It is a best practice to use warnings while writing scripts too. In some cases where the message might be undesirable a certain warning category may be locally disabled within a scope. Additional info is described in 'warnings'.

使用诊断使警告更详细，学习环境，特别是新来者，这是非常可取的。诊断可能会被排除在最终产品之外，但是在开发过程中，它们可以是通常生成的简洁信息的一个很好的补充。您可以在Perl POD诊断中了解诊断。

use diagnostics makes the warnings more verbose, and in a development or learning environment, particularly among newcomers, that's highly desirable. Diagnostics would probably be left out of a 'final product', but while in development they can be a really nice addition to the terse messages normally generated. You can read about diagnostics in the Perl POD "diagnostics."

没有理由强迫自己仅使用上述选项之一。特别是，使用警告和使用严格应该通常都用于现代的Perl程序。

There is no reason to force oneself to use only one of the above options or another. In particular, use warnings and use strict should generally both be used in modern Perl programs.

在所有情况下（除了诊断，你只用于开发） ，个别狭窄或警告可能会被词汇禁用。此外，他们的错误可能被 eval {....} 捕获， Try :: Tiny / catch块，还有一些其他的方法。如果对潜在攻击者发出的有关脚本的更多信息的消息感到担心，则可以将消息路由到日志文件。如果存在所述日志文件消耗大量空间的风险，则存在更大的问题，并且问题的根源应当被解决或者在一些罕见的情况下仅仅是禁用该消息。

In all cases (except diagnostics, which you're only using for development anyway), individual strictures or warnings may be lexically disabled. Furthermore, their errors may be trapped with eval{ .... }, with Try::Tiny's try/catch blocks, and a few other ways. If there's a concern about a message giving a potential attacker more information about a script, the messages could be routed to a logfile. If there's a risk of said logfile consuming lots of space, there's a bigger issue at hand, and the source of the issue should either be resolved or in some rare cases simply have the message disabled.

Perl程序现在应该是高度严格/警告符合作为最佳实践。

Perl programs nowadays should be highly strict/warnings compliant as a best practice.

这篇关于你在Perl使用哪个安全网？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！