是否需要“使用严格”的 Python 编译器？

Is there a need for a "use strict" Python compiler?

提问by cdleary

There exist static analysis tools for Python, but compile time checks tend to be diametrically opposed to the run-time binding philosophythat Python embraces. It's possibleto wrap the standard Python interpreter with a static analysis tool to enforce some "use strict"-like constraints, but we don't see any widespread adoption of such a thing.

Python存在静态分析工具，但编译时检查往往与Python 所采用的运行时绑定哲学截然相反。这是可能的包装标准Python解释器静态分析工具来执行一些“使用严格”般的约束，但我们没有看到任何广泛采用的这样的事情。

Is there something about Python that makes "use strict" behavior unnecessary or especially undesirable?

Python 是否有一些东西使“使用严格”行为变得不必要或特别不可取？

Alternatively, is the "use strict" behavior unnecessary in Perl, despite its widespread adoption?

或者，尽管 Perl 被广泛采用，“严格使用”行为在 Perl 中是不必要的吗？

Note: By "necessary" I mean "practically necessary", not strictly necessary. Obviously you canwrite Perl without "use strict," but (from what I've seen) most Perl programmers douse it.

注意：“必要”是指“实际必要”，而不是绝对必要。显然，您可以在不使用“严格使用”的情况下编写 Perl，但是（根据我所见）大多数 Perl 程序员确实使用它。

Note: The Python interpreter-wrapper need not require"use strict"-like constraints -- you could use a pseudo-pragma similar to "use strict" that would be ignored by the normal interpreter. I'm not talking about adding a language-level feature.

注：Python解释器的包装器不必要求“使用严格”般的约束-你可以使用一个伪编译类似于“使用严格”，将通过正常的解释被忽略。我不是在谈论添加语言级别的功能。

---

---

Update: Explaining what "use strict" does in Perl per comments. (Link to official docs is in the first paragraph.)

更新：解释每条评论在 Perl 中“使用严格”的作用。（官方文档的链接在第一段。）

The "use strict" directive has three distinct components, only two of which are really interesting:

“use strict”指令包含三个不同的组件，其中只有两个非常有趣：

• use strict vars: Statically checks lexically scoped variable usage in your program. (Keep in mind that, in Python, there is basically only globalscope and localscope). Many Python linters check for this sort of thing. Since it's the only static analysis that they can do, the linters assume you use straightforward lexical scoping and warn you about things that appear wrong in that sense until you tell them to shut up; i.e.

  FOO = 12
  foo += 3
  

  If you're not doing anything fancy with your namespaces this can be useful to check for typos.

• use strict refs: Prevents symbolic namespace dereferencing. Python's closest analog is using locals()and globals()to do symbolic binding and identifier lookup.

• use strict subs: No real analog in Python.

• use strict vars：静态检查程序中词法作用域变量的使用情况。（请记住，在 Python 中，基本上只有global作用域和local作用域）。许多 Python linter 检查此类事情。因为这是他们唯一可以做的静态分析，所以 linter 假设您使用简单的词法范围并警告您从这个意义上说似乎错误的事情，直到您告诉他们闭嘴；IE

  FOO = 12
  foo += 3
  

  如果您没有对命名空间做任何花哨的事情，这对于检查拼写错误很有用。

• 使用严格引用：防止符号命名空间取消引用。Python 最接近的模拟是使用locals()和globals()进行符号绑定和标识符查找。

• 使用严格的 subs：在 Python 中没有真正的模拟。

采纳答案by S.Lott

"the run-time binding philosophy that Python embraces... makes "use strict" behavior unnecessary [and] especially undesirable"

“Python 所采用的运行时绑定哲学......使得“严格使用”行为变得不必要 [并且] 尤其不可取”

Pretty good summary. Thanks.

很不错的总结。谢谢。

That is essentially it. Static analysis tools don't help Python enough to be worthwhile.

基本上就是这样。静态分析工具对 Python 的帮助还不够值得。

---

---

Edit

编辑

"I'm asking for us to introspect on whywe don't need it and, relatedly, why Perl programmers think they do need it."

“我要求我们反省为什么我们不需要它，以及相关地，为什么 Perl 程序员认为他们确实需要它。”

The reason why is precisely the reason you already gave. We don't need it because it doesn't help. Clearly, you don't like that answer, but there's not much more to be said. Compile-time or pre-compile time checking simply does not help.

原因正是你已经给出的原因。我们不需要它，因为它没有帮助。很明显，你不喜欢那个答案，但也没什么好说的了。编译时或预编译时检查根本没有帮助。

However, since you took the time to asked the question again, I'll provide more evidence for the answer you already gave.

不过，既然你又花时间问了这个问题，我会为你已经给出的答案提供更多证据。

I write Java almost as much as I write Python. Java's static type checking does not prevent any logic problems; it doesn't facilitate meeting performance requirements; it doesn't help meet the use cases. It doesn't even reduce the volume of unit testing.

我写 Java 几乎和我写 Python 一样多。Java 的静态类型检查并不能防止任何逻辑问题；它不利于满足性能要求；它无助于满足用例。它甚至不会减少单元测试的数量。

While static type checking does spot the occasional misuse of a method, you find this out just as quickly in Python. In Python you find it at unit test time because it won't run. Note: I'm not saying wrong types are found with lots of clever unit tests, I'm saying most wrong type issues are found through unhandled exceptions where the thing simply won't run far enough to get to test assertions.

虽然静态类型检查确实会发现方法的偶然误用，但您在 Python 中也能很快地发现这一点。在 Python 中，您会在单元测试时找到它，因为它不会运行。注意：我并不是说通过大量巧妙的单元测试发现错误类型，我是说大多数错误类型问题是通过未处理的异常发现的，在这些异常中，事情根本不会运行到足以测试断言的程度。

The reason why is Pythonistas don't waste time on static checking is simple. We don't need it. It doesn't offer any value. It's a level of analysis that has no economic benefit. It doesn't make me any more able to solve the real problems that real people are having with their real data.

Pythonistas 不浪费时间在静态检查上的原因很简单。我们不需要它。它不提供任何价值。这是一种没有经济利益的分析水平。它并没有让我更能够解决真实的人在使用真实数据时遇到的真实问题。

Look at the most popular SO Python questions that are language (not problem domain or library) related.

查看与语言（不是问题域或库）相关的最流行的 SO Python 问题。

Is there any difference between "foo is None" and "foo == None"?-- ==vs. is. No static checking can help with this. Also, see Is there a difference between `==` and `is` in Python?

“foo is None”和“foo == None”之间有什么区别吗？——==对is. 没有静态检查可以帮助解决这个问题。另外，请参阅Python 中的 `==` 和 `is` 之间有区别吗？

What does ** (double star) and * (star) do for parameters?-- *xgives a list, **xgives a dictionary. If you don't know this, your program dies immediately when you try to do something inappropriate for those types. "What if your program never does anything 'inappropriate'". Then your program works. 'nuff said.

**（双星）和*（星）对参数有什么作用？--*x给出一个列表，**x给出一个字典。如果您不知道这一点，那么当您尝试为这些类型做一些不合适的事情时，您的程序会立即终止。“如果你的程序从不做任何‘不恰当的’事情怎么办”。然后你的程序就可以工作了。'纳夫说。

How can I represent an 'Enum' in Python?-- this is a plea for some kind of limited-domain type. A class with class-level values pretty much does that job. "What if someone changes the assignment". Easy to build. Override __set__to raise an exception. Yes static checking might spot this. No, it doesn't happen in practice that someone gets confused about an enum constant and a variable; and when they do, it's easy to spot at run time. "What if the logic never gets executed". Well, that's poor design and poor unit testing. Throwing a compiler error and putting in wrong logic that's never tested is no better than what happens in a dynamic language when it's never tested.

如何在 Python 中表示“枚举”？——这是对某种有限域类型的请求。具有类级别值的类几乎可以完成这项工作。“如果有人更改任务怎么办”。易于构建。覆盖__set__以引发异常。是的，静态检查可能会发现这一点。不，在实践中不会发生有人对枚举常量和变量感到困惑；当他们这样做时，很容易在运行时发现。“如果逻辑永远不会被执行怎么办”。嗯，这是糟糕的设计和糟糕的单元测试。抛出编译器错误并放入从未测试过的错误逻辑并不比动态语言中从未测试过的情况好。

Generator Expressions vs. List Comprehension-- static checking doesn't help resolve this question.

Generator Expressions vs. List Comprehension——静态检查无助于解决这个问题。

Why does 1+++2 = 3?-- static checking wouldn't spot this. 1+++2 in C is perfectly legal in spite of all the compiler checking. It's not the same thing in Python as it is in C, but just as legal. And just as confusing.

为什么 1+++2 = 3？- 静态检查不会发现这一点。尽管进行了所有编译器检查，但 C 中的 1+++2 是完全合法的。它在 Python 中与在 C 中不同，但同样合法。同样令人困惑。

List of lists changes reflected across sublists unexpectedly-- This is entirely conceptual. Static checking can't help solve this problem either. The Java equivalent would also compile and behave badly.

意外反映在子列表中的列表更改列表- 这完全是概念性的。静态检查也无助于解决这个问题。Java 等价物也会编译和运行不良。

回答by daotoad

Well, I'm not much of a python programmer, but I'd say that the answer is 'YES'.

好吧，我不是一个 Python 程序员，但我会说答案是“是”。

Any dynamic language that lets you create a variable with any name at any time, could use a 'strict' pragma.

任何允许您随时创建具有任何名称的变量的动态语言都可以使用“严格”编译指示。

Strict vars (one of the options for strict in Perl, 'use strict' turns them all on at once) in Perl requires that all variables are declared before they are used. Which means that this code:

Perl 中的 Strict 变量（Perl 中的 strict 选项之一，'use strict' 将它们一次全部打开）要求在使用之前声明所有变量。这意味着这段代码：

my $strict_is_good = 'foo';
$strict_iS_good .= 'COMPILE TIME FATAL ERROR';

Generates a fatal error at compile time.

在编译时产生致命错误。

I don't know of a way to get Python to reject this code at compile time:

我不知道有什么方法可以让 Python 在编译时拒绝此代码：

strict_is_good = 'foo';
strict_iS_good += 'RUN TIME FATAL ERROR';

You will get a run-time exception that strict_iS_goodis undefined. But only when the code is executed. If your test suite does not have 100% coverage, you can easily ship this bug.

你会得到一个strict_iS_good未定义的运行时异常。但只有当代码被执行时。如果您的测试套件没有 100% 的覆盖率，您可以轻松地发布此错误。

Any time I work in a language that does not have this behavior (PHP for example), I get nervous. I am not a perfect typist. A simple, but hard to spot, typo can cause your code to fail in ways that may be hard to track down.

每当我使用没有这种行为的语言（例如 PHP）工作时，我都会感到紧张。我不是一个完美的打字员。一个简单但难以发现的错字可能会导致您的代码以难以追踪的方式失败。

So, to reiterate, YESPython could use a 'strict' pragma to turn on compile time checks for things that can be checked at compile time. I can't think of any other checks to add, but a better Python programmer probably could think of some.

因此，重申一下，YESPython 可以使用“严格”编译指示来为可以在编译时检查的内容打开编译时检查。我想不出要添加任何其他检查，但更好的 Python 程序员可能会想到一些。

NoteI focus on the pragmatic effect of stict vars in Perl, and am glossing over some of the details. If you really want to know all the details see the perldoc for strict.

注意我专注于 Perl 中 stict vars 的实用效果，并掩盖了一些细节。如果您真的想知道所有详细信息，请参阅严格的 perldoc。

Update: Responses to some comments

更新：对一些评论的回应

Jason Baker: Static checkers like pylint are useful. But they represent an extra step that can be and often is skipped. Building some basic checks into the compiler guarantees that these checks are performed consistently. If these checks are controllable by a pragma, even the objection relating to the cost of the checks becomes moot.

Jason Baker：像 pylint 这样的静态检查器很有用。但它们代表了可以并且经常被跳过的额外步骤。在编译器中构建一些基本检查可确保这些检查一致执行。如果这些检查可以通过 pragma 进行控制，那么即使是与检查成本相关的反对意见也变得没有实际意义。

popcnt: I know that python will generate a run time exception. I said as much. I advocate compile time checking where possible. Please reread the post.

popcnt：我知道python会产生一个运行时异常。我说了这么多。我提倡在可能的情况下进行编译时检查。请重新阅读帖子。

mpeters: No computer analysis of code can find all errors--this amounts to solving the halting problem. Worse, to find typos in assignments, your compiler would need to know your intentionsand find places where your intentions differ from your code. This is pretty clearly impossible.

mpeters：没有任何计算机分析代码可以找到所有错误——这相当于解决了停机问题。更糟糕的是，要查找作业中的拼写错误，您的编译器需要了解您的意图并找到您的意图与代码不同的地方。这显然是不可能的。

However this does not mean that no checking should be done. If there are classes of problems that are easy to detect, then it makes sense to trap them.

然而，这并不意味着不应该进行检查。如果存在易于检测的问题类别，那么捕获它们是有意义的。

I'm not familiar enough with pylint and pychecker to say what classes of errors they will catch. As I said I am very inexperienced with python.

我对 pylint 和 pychecker 不够熟悉，无法说明它们会捕获哪些类型的错误。正如我所说，我对 python 非常缺乏经验。

These static analysis programs are useful. However, I believe that unless they duplicate the capabilities of the compiler, the compiler will always be in a position to "know" more about the program than any static checker could. It seems wasteful not to take advantage of this to reduce errors where possible.

这些静态分析程序很有用。但是，我相信，除非它们复制编译器的功能，否则编译器将始终比任何静态检查器都能够“了解”更多有关程序的信息。在可能的情况下不利用这一点来减少错误似乎是浪费。

Update 2:

更新 2：

cdleary - In theory, I agree with you, a static analyzer can do any validation that the compiler can. And in the case of Python, it should be enough.

cdleary - 从理论上讲，我同意您的看法，静态分析器可以执行编译器可以执行的任何验证。而在 Python 的情况下，应该足够了。

However, if your compiler is complex enough (especially if you have lots of pragmas that change how compilation occurs, or if like Perl, you can run code at compile time), then the static analyzer must approach the complexity of the compiler/interpreter to do the analysis.

然而，如果你的编译器足够复杂（特别是如果你有很多 pragma 改变编译方式，或者像 Perl 一样，你可以在编译时运行代码），那么静态分析器必须接近编译器/解释器的复杂性做分析。

Heh, all this talk of complex compilers and running code at compile time shows my Perl background.

嘿，所有这些关于复杂编译器和在编译时运行代码的讨论都显示了我的 Perl 背景。

My understanding is that Python does not have pragmas and can not run arbitrary code at compile time. So, unless I am wrong or these features are added, a relatively simple parser in the static analyzer should suffice. It certainly would be helpful to force these checks at every execution. Of course, the way I'd do this is with a pragma.

我的理解是 Python 没有编译指示，不能在编译时运行任意代码。所以，除非我错了或者添加了这些特性，静态分析器中一个相对简单的解析器就足够了。在每次执行时强制执行这些检查肯定会有所帮助。当然，我这样做的方法是使用 pragma。

Once you add pragmas to the mix, you have started down a slippery slope and the complexity of you analyzer must grow in proportion to the power and flexibility you provide in your pragmas. If you are not careful, you can wind up like Perl, and then "only python can parse Python," a future I wouldn't want to see.

一旦您将编译指示添加到混合中，您就开始了一个滑坡，分析器的复杂性必须与您在编译指示中提供的功能和灵活性成比例地增长。一不小心，就会像 Perl 一样，然后“只有 python 才能解析 Python”，这是我不想看到的未来。

Maybe a command line switch would be a better way to add forced static analysis ;)

也许命令行开关是添加强制静态分析的更好方法；)

(In no way do intend to impugn Python's capabilities when I say that it can't futz with compile time behavior like Perl can. I have a hunch that this is a carefully considered design decision, and I can see the wisdom in it. Perl's extreme flexibility at compile time is, IMHO, a great strength and a terrible weakness of the language; I see the wisdom in this approach as well.)

（当我说 Python 不能像 Perl 那样与编译时行为相冲突时，绝不打算指责 Python 的功能。我有一种预感，这是一个经过深思熟虑的设计决策，我可以看到其中的智慧。Perl 的恕我直言，编译时的极端灵活性是语言的巨大优势和可怕的弱点；我也看到了这种方法的智慧。）

回答by bobince

Python does have something that can change script syntax:

Python 确实有一些可以改变脚本语法的东西：

from __future__ import print_function

and various other future-features that have syntax implications. It's just that Python's syntax has been stricter, stabler and more well-defined than historical Perl; the kind of things that ‘strict refs' and ‘strict subs' prohibit have never existed in Python.

以及具有语法含义的各种其他未来功能。只是 Python 的语法比历史上的 Perl 更严格、更稳定、定义更明确；'strict refs' 和 'strict subs' 禁止的那种东西在 Python 中从未存在过。

‘strict vars' is primarily intended to stop typoed references and missed-out ‘my's from creating accidental globals (well, package variables in Perl terms). This can't happen in Python as bare assignments default to local declaration, and bare unassigned symbols result in an exception.

'strict vars' 主要是为了阻止输入错误的引用和遗漏的 'my's 创建意外的全局变量（好吧，Perl 术语中的包变量）。这在 Python 中不会发生，因为裸赋值默认为局部声明，而裸未赋值的符号会导致异常。

(There is still the case where users accidentally try to write-through to a global without declaring it with a ‘global' statement, causing either an accidental local or, more often, an UnboundLocalError. This tends to be learned fairly quickly, but it is an arguable case where having to declare your locals could help. Although few experienced Python programmers would accept the readability burden.)

（仍然存在这样的情况，即用户不小心尝试直写到全局变量而没有使用“全局”语句声明它，从而导致意外的本地错误或更常见的是 UnboundLocalError。这往往很快就会学会，但它是一个有争议的案例，必须声明您的本地人可能会有所帮助。尽管很少有经验丰富的 Python 程序员会接受可读性负担。）

Other language and library changes that do not involve syntax are handled through the warningssystem.

不涉及语法的其他语言和库更改通过警告系统处理。

回答by mpeters

I think there's some confusion as the what "use strict" does, from the comments I'm seeing. It does not turn on compile time type checks (to be like Java). In that sense, Perl progammers are in agreement with python programmers. As S.Lott says above these types of checks don't protect against logic bugs, don't reduce the number of unit tests you need to write and we're also not big fans of bondage programming.

从我看到的评论来看，我认为“严格使用”的含义有些混乱。它不会打开编译时类型检查（就像 Java 一样）。从这个意义上说，Perl 程序员与 Python 程序员是一致的。正如上面 S.Lott 所说，这些类型的检查不能防止逻辑错误，也不能减少您需要编写的单元测试的数量，而且我们也不是束缚编程的忠实粉丝。

Here's a list of what "use strict" does do:

以下是“use strict”所做的事情的列表：

1. Using symbolic references is a run-time error. This prevents you from doing crazy (but sometimes useful things like)

   $var = 'foo';

   $foo = 'bar';

   print $$var; # this would contain the contents of $foo unless run under strict

2. Using undeclared variables is a run-time error (this means you need to use "my", "our" or "local" to declare your variable's scope before using it.

3. All barewords are considered compile-time syntax errors. Barewords are words that have not been declared as symbols or subroutines. This is mainly to outlaw something that was historically done but is considered to have been a mistake.

1. 使用符号引用是一个运行时错误。这可以防止你做疯狂的事情（但有时有用的东西，比如）

   $var = 'foo';

   $foo = 'bar';

   print $$var; # this would contain the contents of $foo unless run under strict

2. 使用未声明的变量是一个运行时错误（这意味着您需要在使用之前使用“my”、“our”或“local”来声明变量的作用域。

3. 所有裸词都被视为编译时语法错误。裸字是尚未声明为符号或子程序的字。这主要是为了取缔历史上做过但被认为是错误的事情。

回答by Leon Timmermans

Python has no true lexical scoping, so strict vars wouldn't be very sensible. It has no symbolic references AFAIK, so it has not need for strict refs. It has not barewords, so it has no need for strict vars.

Python 没有真正的词法范围，所以严格的 vars 不是很明智。它没有符号引用 AFAIK，所以它不需要严格的引用。它没有裸词，因此不需要严格的变量。

To be honest, it's only lexical scoping I miss. The other two I'd consider warts in Perl.

老实说，这只是我想念的词汇范围。另外两个我认为是 Perl 中的疣。

回答by Rob Prentice

This original answer is correct, but does not perhaps explain the situation in a practical sense.

这个原始答案是正确的，但可能并没有从实际意义上解释这种情况。

There exist static analysis tools for Python, but compile time checks tend to be >diametrically opposed to the run-time binding philosophy that Python embraces.

Python 存在静态分析工具，但编译时检查往往与 Python 所采用的运行时绑定哲学截然相反。

What 'use strict' provides in Perl is the ability to ensure that a mis-spelled or variable name is (usually) caught at compile-time. This does improve code reliability, and speeds up development. But in order to make such a thing worthwhile, you need to declare variables. And Python style seems to discourage that.

Perl 中的“use strict”提供的是确保（通常）在编译时捕获拼写错误或变量名称的能力。这确实提高了代码的可靠性，并加快了开发速度。但是为了让这样的事情变得有价值，你需要声明变量。而 Python 风格似乎不鼓励这样做。

So in Python, you never find out about a mis-spelled variable until you notice at run-time that the assignment you thought you made is not being made, or that an expression seems to resolve to an unexpected value. Catching such errors can be time-consuming, especially as programs get large, and as people are forced to maintain code developed by others.

因此，在 Python 中，您永远不会发现拼写错误的变量，直到您在运行时注意到您认为自己所做的赋值没有进行，或者表达式似乎解析为意外的值。捕获此类错误可能非常耗时，尤其是在程序变大以及人们被迫维护他人开发的代码时。

Java and C/C++ take it a step further, with type checking. The motivation is practical, rather than philosophical. How can you catch as many errors as possible as soon as possible, and be sure that you eliminate all of them before releasing code to production? Each language seems to take a particular strategy and run with it, based upon what they think is important. In a language like Perl, where run-time binding isn't supported, it makes sense to take advantage of 'use strict' to make development easier.

Java 和 C/C++ 更进一步，通过类型检查。动机是实际的，而不是哲学的。如何尽快捕获尽可能多的错误，并确保在将代码发布到生产环境之前消除所有错误？每种语言似乎都采用特定的策略并根据它们认为重要的内容运行。在像 Perl 这样不支持运行时绑定的语言中，利用“use strict”来简化开发是有意义的。

回答by popcnt

I consider the 'use strict'in Perl more like a pragma as you hinted at: it changes the behavior of the compiler.

我认为'use strict'Perl 中的 更像是您暗示的编译指示：它改变了编译器的行为。

Perl language philosophy is different from python philosophy. As in, you are given more than enough rope to hang yourself repeatedly, in Perl.

Perl 语言哲学不同于 python 哲学。就像在 Perl 中一样，你有足够多的绳子让你反复上吊。

Larry Wall is big into linguistics, so we have from Perl what is referred to as the TIMTOWTDI (say tim-toe-dee) principle vs. Zen of python:

Larry Wall 对语言学很感兴趣，所以我们从 Perl 得到了所谓的 TIMTOWTDI（比如tim-toe-dee）原则与 Python 的 Zen：

There should be one-- and preferably only one --obvious way to do it.

应该有一种——最好只有一种——明显的方法来做到这一点。

you could very easily use pylint and PyChecker to come up with your own flavor of use strictfor python (or something analogous to perl -cw *scriptname*) but because of the different philosophies in the language design, you will not encounter this in practice widely.

你可以很容易地使用 pylint 和 PyChecker 来想出你自己的use strictfor python（或类似的东西perl -cw *scriptname*）的风格，但由于语言设计中的不同哲学，你不会在实践中广泛地遇到这种情况。

Based on your comment to the first poster, you are familiar with python's import this. There are a lot of things in there which illuminate why you do not see an equivalent of use strictin Python. If you meditate on the koanfound in the Zen of Python, you may find enlightenment for yourself. :)

根据您对第一张海报的评论，您熟悉 python 的import this. 那里有很多东西可以说明为什么use strict在 Python中看不到等效的东西。如果您冥想Python 之禅中的公案，您可能会发现自己的启蒙。:)

回答by DNS

I've found that I only really care about detecting references to undeclared vars. Eclipse has pylint integration via PyDev and, although pylint is far from perfect, it does a reasonable job at that.

我发现我只关心检测对未声明变量的引用。Eclipse 通过 PyDev 集成了 pylint，虽然 pylint 远非完美，但它在这方面做得不错。

It does kind of go against Python's dynamic nature, and I do have to add #IGNOREs occasionally, when my code gets clever about something. But I find that happens infrequently enough that I'm happy with it.

它确实有点违背 Python 的动态特性，当我的代码变得聪明时，我必须偶尔添加 #IGNOREs。但我发现这种情况很少发生，我对此很满意。

But I could see the utility of some pylint-like functionality becoming available in the form of a command-line flag. Kind of like Python 2.6's -3 switch, which identifies points of incompatibility between Python 2.x and 3.x code.

但是我可以看到一些类似 pylint 的功能的效用以命令行标志的形式变得可用。有点像 Python 2.6 的 -3 开关，它标识了 Python 2.x 和 3.x 代码之间的不兼容点。

回答by sammy

It is very difficult to write large programs without 'use strict' in Perl. Without 'use strict', if you use a variable again, and misspell it by leaving a letter out, the program still runs. And without test cases to check your results, you can never find such errors. It can be very time-consuming to find why you are getting wrong results due to this reason.

在 Perl 中没有“严格使用”就很难编写大型程序。如果没有'use strict'，如果你再次使用一个变量，并通过遗漏一个字母来拼错它，程序仍然运行。如果没有测试用例来检查您的结果，您将永远找不到此类错误。找出由于这个原因得到错误结果的原因可能非常耗时。

Some of my Perl programs consist of 5,000 lines to 10,000 lines of code broken into dozens of modules. One cannot really do production programming without 'use strict'. I would never allow production code to be installed in the factory with languages that do not enforce "variable declarations".

我的一些 Perl 程序由 5,000 行到 10,000 行代码组成，这些代码被分成了几十个模块。如果没有“严格使用”，就无法真正进行生产编程。我永远不会允许在工厂中使用不强制执行“变量声明”的语言安装生产代码。

This is why Perl 5.12.x now has the 'use strict' as the default behavior. You can turn them off.

这就是为什么 Perl 5.12.x 现在将“使用严格”作为默认行为。您可以关闭它们。

PHP has given me quite a few problems because of no variable declaration enforcement. So you need to limit yourself to small programs with this language.

由于没有强制执行变量声明，PHP 给我带来了很多问题。所以你需要限制自己使用这种语言的小程序。

Just an opinion ...

只是一个意见...

abcParsing

abc解析

回答by BinDu

Perl is a unrestrained language as they said :) . So you can use the variable before announced ; Eg : If you use a var name "is_array" but type in "is_arrby" ,the compiler won't report error without "use strict" . So when coding long program in perl ,better use "use strict" statement. Of course, less than 50 lines for running one time script, there is no need :)

正如他们所说，Perl 是一种无拘无束的语言 :) 。所以你可以在宣布之前使用这个变量；例如：如果您使用 var 名称 "is_array" 但键入 "is_arrby" ，则编译器不会在没有 "use strict" 的情况下报告错误。所以在用 perl 编写长程序时，最好使用“use strict”语句。当然，运行一次脚本少于 50 行，没有必要:)