证明克罗克福德声称 [英] Justifying Crockford claims

问题描述

我读过Crockford的 JavaScript：The Good Parts 并使用了他的验证器 JSLint 。我有时会想知道他的建议背后的理由。下面列出了我想要证实的例子。

I have read Crockford's JavaScript: The Good Parts and have used his validator JSLint. I am sometimes left wondering the justification behind his recommendations. Below is a list of examples I want substantiated.

1. 为什么JSLint信号如果您不包含use strict，则会出错; ？ [见这个SO线程。]

为什么函数中的变量声明应该使用单个 var ？ [请参阅此SO主题。]

Why should variable declarations within a function be done using a single var? [See this SO thread.]

为什么我们需要在 function 和（）之间加一个空格code> function（）？

Why do we need to put a space between function and () in function ()?

为什么我们不能使用继续？

++ 和有什么问题 - - ？

为什么我们不能使用逗号运算符， （的语句的初始化和增量部分除外）？ [见此博文。]

Why can't we use the comma operator , (except in the initialisation and incrementation parts of the for statement)? [See this blog post.]

为什么每个语句都以; 结尾？ [见此博客文章。]

Why should every single statement end with ;? [See this blog post.]

推荐答案

JSLint的大部分行为都在 JSLint说明页面。从现在开始，我将把它称为JIP。

Much of the behavior of JSLint is explained on the JSLint instructions page. I will refer to it as the JIP from now on.

JIP未解释的大部分行为都是由 JavaScript编程语言的代码约定。我将从现在开始将其称为CCJPL。

Much of the behavior that is not explained by the JIP is explained by Code Conventions for the JavaScript Programming Language by Crockford. I will refer to it as the CCJPL from now on.

要列表：

1） 如果您不包含use strict，为什么JSLint会发出错误信息; ？

1) Why does JSLint signal an error if you don't include "use strict";?

因为严格模式强制执行许多良好实践; JSLint也是关于强制执行良好实践的，所以这就是它的行为。查看use strict启用有助于澄清此事。我只是在Resig的这篇博文中列出来，因此给予应有的信誉。我不会评论它所做的一切，因为我不确定Crockford对每个功能的确切推理。

Because strict mode enforces many good practices; JSLint is all about enforcing good practices too, so naturally this is its behavior. Looking at what "use strict" enables helps clarify the matter. I'm simply going down the list of this blog post by Resig, so due credit is given there. I'm not commenting on everything it does because I'm not sure of exact reasoning from Crockford for every feature.

1. 必须声明变量在分配值之前使用 var ：这会阻止隐式全局变量出现。全球变量被Crockford视为是邪恶的，这有助于消除你没有明确设置的全局变量。


2. 有几个限制了eval，根据 JIP 。


3. 它使用语句禁用。这是由Crockford认为有害的。



1. Variables must be declared with var before you can assign a value: this stops implicit globals from appearing. Global variables are considered by Crockford to be evil, and this helps eliminate globals you didn't explicitly set.
2. It several restricts eval, which Crockford considers to be evil as per the JIP.
3. It disables the with statement. This is considered by Crockford to be harmful.

我只跳过严格模式的两个功能： delete 语句正在修改的行为并覆盖参数变量。我不知道Crockford是否同意或不同意这两件事，但鉴于他帮助创建了ECMAScript 5标准，我倾向于同意。

I only skipped out on two features of strict mode: the delete statement's behavior being modified and overwriting the arguments variable. I don't know if Crockford agrees or disagrees with these two things, but given that he helped create the ECMAScript 5 standard, I would lean towards agree.

2）为什么函数中的变量声明应该使用单个 var 完成？

2) Why should variable declarations within a function be done using a single var?

首先，任何未被 var 声明而定义的变量都是隐式全局变量，根据 JIP ，可以掩盖拼写错误的名字和其他问题。所以，这就是需要 var 的推理。

First, any variable that is defined without being declared by var is implicitly global, which, according to the JIP, can "mask misspelled names and other problems." So, that is the reasoning requiring var.

至于要求一个 var ，所有变量声明由JavaScript引擎自动提升到其范围的顶部，所以我唯一的猜测是Crockford希望开发人员敏锐地意识到这种行为。过去，这可能是一种风格问题。您更喜欢以下两段代码：

As for requiring one var, all variable declarations are hoisted to the top of their scope by the JavaScript engine automatically, so my only guess is that Crockford wishes for the developer to be acutely aware of this behavior. Past that, it's probably a matter of style. Which do you prefer between the two following pieces of code:

var a, b, c;

或

var a; var b; var c;

我的猜测是Crockford认为多个 var 那里很难看。我同意他的观点。

My guess is that Crockford thinks the multiple vars are ugly there. I agree with him on that point.

具有讽刺意味的是，根据 CCJPL ，他实际上建议在不同行上使用相关注释的所有变量声明。 JSLint在这方面不同意他的看法！

Ironically, as per the CCJPL, he actually suggests having all of the variable declarations on different lines with associated comments. JSLint disagrees with him in this regard!

3）为什么我们需要在函数之间加一个空格和（） in function（）？

3) Why do we need to put a space between function and () in function ()?

这仅将 应用于匿名函数。根据 CCJPL ，这是因为：

This applies only to anonymous functions. As per the CCJPL, it is because:

如果函数文字是匿名的，则
单词函数和（左括号）之间应该有一个空格。如果空格是
omited，那么它可以看出函数的名称是函数，
是一个不正确的读数。

If a function literal is anonymous, there should be one space between the word function and the ( (left parenthesis). If the space is omited, then it can appear that the function's name is function, which is an incorrect reading.

当我在学习的时候JavaScript，我虔诚地开始遵循Crockford的惯例......但我的逻辑部分说如果你有一个命名函数函数的代码，它可能迫切需要重新修改。（更不用说在JavaScript中，它是一个 SyntaxError ，因为函数是一个关键字。）

When I was in the thick of learning JavaScript, I religiously began following Crockford's conventions... but the logical part of me says that if you have code that names a function function, it's probably in dire need of reworking anyways. (Not to mention that in JavaScript, it's a SyntaxError because function is a keyword.)

4）为什么我们不能使用继续？

4) Why can't we use continue?

引用 CCJPL ：

它往往会掩盖函数的控制流。

It tends to obscure the control flow of the function.

不完全是一个精心设计的答案，但我在互联网上看到的论点与 goto 相比较。按照你的意愿去做。

Not exactly an elaborate answer, but I've seen arguments on the internet comparing it to goto. Take that as you will.

5） ++ 和<$ c $有什么问题c> - ？

5) What is wrong with ++ and --?

正如在 JIP ：

++（增量）和 - （减量）运营商已经知道
通过鼓励过度的诡计来弥补不良代码。它们只能在故障架构中获得b
，从而实现病毒和其他
安全威胁。此外，增加前/后增量混淆可以
产生一个非常难以诊断的错误。

The ++ (increment) and -- (decrement) operators have been known to contribute to bad code by encouraging excessive trickiness. They are second only to faulty architecture in enabling to viruses and other security menaces. Also, preincrement/postincrement confusion can produce off-by-one errors that are extremely difficult to diagnose.

6） 为什么我们不能使用逗号运算符，（除了的初始化和增量部分声明）？

6) Why can't we use the comma operator , (except in the initialisation and incrementation parts of the for statement)?

来自 JIP ：

逗号运算符可能导致过于棘手的表达式。它可以
也掩盖了一些编程错误。

The comma operator can lead to excessively tricky expressions. It can also mask some programming errors.

这是一个真正的耻辱，因为你链接的博客文章显示，在某些情况下，逗号运算符确实可以提高代码的清晰度。

This is a real shame, because as the blog post you linked shows, the comma operator can really increase the clarity of code in some situations.

在Crockford的许多约定中，您会注意到一个共同的基础主题：可理解的可读代码。这只是另一个例子。许多约定集中在拒绝访问棘手表达式。

You will notice a common underlying theme throughout many of Crockford's conventions: understandable, readable code. This is just another example of that. Many conventions are centered around denying access to 'tricky' expressions.

但我认为我用来描述其中一些表达的真实词语是简洁 - 本身并不一定是坏事，但是如果错误地使用它可能是邪恶的。 Crockford的约定有时试图通过删除这些表达式使用的一些工具来粉碎错误使用的简洁性，即使它们在某些情况下具有合法用途。

But I think the real word I'd use to describe some of these expressions would be 'terse' -- which is not necessarily a bad thing, per se, but it can be evil if used wrongly. Crockford's conventions sometimes try to smash wrongly-used-terseness by removing some of the tools these expressions use, even if they have legitimate uses in some contexts.

7）为什么每个语句都以结尾; ？

7) Why should every single statement end with ;?

再次引用 JIP ：

JavaScript使用类似C的语法，需要使用分号
来分隔某些语句。 JavaScript尝试使用分号插入机制使这些
分号可选。这是
危险，因为它可以掩盖错误。

JavaScript uses a C-like syntax which requires the use of semicolons to delimit certain statements. JavaScript attempts to make those semicolons optional with a semicolon insertion mechanism. This is dangerous because it can mask errors.

像C一样，JavaScript有++和 - 和（运营商可以是前缀
或消歧由分号完成。

Like C, JavaScript has ++ and -- and ( operators which can be prefixes or suffixes. The disambiguation is done by the semicolon.

通常我发现Crockford的解释中的'可掩盖错误'部分相当宽泛并且模糊，但分号插入实际上是我可以全心全意同意的一个领域。在每个语句之后使用显式分号比使用分号插入的危险水域缩小风险更容易。

Usually I find the 'can mask errors' part of Crockford's explanations to be rather broad and vague, but semicolon insertion is really one area where I can agree wholeheartedly. It's easier to use explicit semicolons after every statement than risk narrowing the dangerous waters of semicolon insertion.

以下是 JavaScript语法维基百科页面中出现分号插入错误的典型示例：

Here is a classic example of semicolon insertion gone wrong from the Wikipedia page on JavaScript Syntax:

return
a + b;

// Returns undefined. Treated as:
//   return;
//   a + b;

如果你使用像这样的对象文字来自这篇博客文章（一种相当常见的大括号），那么它就会搞乱你也是：

And if you use an object literal like the code from this blog post (a fairly common style of braces), then it can mess you up too:

function shoeFactory() {
    return // <--- semicolon inserted here
    {
        shoeSize: 48
    };
}

var shoe = shoeFactory();
console.log(shoe); // undefined

上述维基百科文章的另一个例子：

Another example from the above Wikipedia article:

a = b + c
(d + e).foo()

// Treated as:
//   a = b + c(d + e).foo();

我也从来没有真正被添加明确的分号所扰乱。在编写几乎任何代码时，他们非常自然地来找我。事实上，我经常发现自己在Python中使用分号，即使它们不是必需的。

I've never really been perturbed by adding explicit semicolons, either. They come to me very naturally when writing almost any code. In fact, I often catch myself putting semicolons in Python even though they're not necessary.

在这种情况下，我非常同意Crockford的意见。我认为一个关于分号插入的调试会话可能会让大多数人相信将它们放在代码中会更容易。

In this case, I agree pretty wholeheartedly with Crockford. I think one debugging session concerning semicolon insertion would probably convince most people that it would be easier just to place them in the code.

这篇关于证明克罗克福德声称的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！