JSLint支持If-Block [英] JSLint Braces around If-Block

问题描述

在Javascript中，如果 if 表达式之后没有大括号，则将以下语句放在中，如果阻止。也就是说，

In Javascript, if an if expression does not have a curly bracket after it, the following statement is put inside the if block. That is,

if(foo)
bar();
baz();

相当于

if(foo) {
  bar();
}
baz();

道格拉斯·克罗克福德建议不要使用第一个，因为它令人困惑并且可能导致难以追踪的错误程序员试图在没有大括号的情况下向 if 块添加语句。出于这个原因，JsLint抱怨你是否使用第一个表格。

Douglas Crockford recommends not using the first because it is confusing and can cause hard-to-trace bugs if a programmer tries to add a statement to an if block without braces. For this reason, JsLint complains if you use the first form.

我一直使用这个，如果你把声明放在和相同的行上，我觉得这不是问题声明，如下所示：

I use this all the time, and I feel like it's a non-issue provided that you put the statement on the same line as the if statement, like this:

if(foo) bar();
baz();

这比完整的支架形式更直观，而且我从未对它产生过混淆。就这样我可以通过JsLint并且没有那么多的视觉噪音我有时会使用一种依赖于操作员短路的不那么惯用的形式，如下所示：

This is more concise visually than the full bracket form, and I've never had confusion with it. Just so I could pass JsLint and not have so much visual noise I have sometimes resorted to using a less idiomatic form that relies on operator short-circuiting, like this:

foo && bar();
baz();

你可能都在等我快点问一个问题，所以这里有：
如果正确格式化，在单行条件语句中不使用大括号通常被认为是不好的做法吗？为什么？ JsLint有没有合理的理由抱怨它？

You're probably all waiting for me to hurry up and ask a question, so here it goes: Is it generally considered bad practice to not use braces on one-line conditional statements if you format it correctly? Why? Is there a legitimate reason for JsLint to complain about it?

推荐答案

阅读：

• 您可能不习惯这种编码风格，并且可能认为这会执行两个函数：

• You might not be used to that coding style, and might think that this executes the two functions:

if(foo) bar();
        baz();

由于JS具有自动分号插入功能，因此情况甚至更为晦涩难懂。例如，我对ASI对此代码的处理方式感到不舒服，即使我可以推断出来：

Since JS has automatic semicolon insertion, there are even murkier circumstances. I, for instance, am not comfortable with what ASI would do to this code, even if I can reason it out:

if(foo) bar()
        baz()

不可能弄清楚或如果你知道ASI的作用，那就更难了，但是ASI是一个非常重要的算法。必须在脑中运行它在时间上是昂贵的，所以如果你只是避免模棱两可（在这个意义上，根据ECMA-262规范没有模棱两可）的情况会更好。

It is not impossible to figure out or even hard if you know what ASI does, but ASI is a nontrivial algorithm. Having to run it in your head is expensive in terms of time, so it's better if you simply avoid ambiguous (in this sense, not ambiguous as per the ECMA-262 spec) situations.

它使你的线条比他们需要的更长。根据您的编码惯例，这可能被认为是非问题，如果您的条件很长，并且您的陈述也是如此，由此产生的单行陈述对于要阅读的眼睛会更加沉重（众所周知，您的眼睛难以阅读非常单独的行，因此段落）。

It makes your lines longer than they need to be. This may be considered a non-issue depending on your coding conventions, if your condition is long, and your statement is as well, the resulting single-line statement will be more taxing on the eyes to read (it is well known that your eyes have difficulty reading very lone lines, hence paragraphing).

如果你出于某种原因，尽管有大括号，你仍然可以使用以下形式的东西：

You can, if you for some reason despite braces, still use something of the form:

if(foo)
    bar();

这几乎与您的代码相同，但我认为没有理由，不要只是把括号放在那里。

And that is virtually identical to the code you had, but I see no reason, at that point, not to just put the braces there.

写作：

• 当您需要添加另一个语句时，您不会简单地编写它。您必须重构周围区域才能执行此操作。同样，这并不难，但这是一个值得考虑的事情，这既不是你的问题也不是问题的解决方案，它只是一个语法上的怪癖。

• When you need to add another statement, it is not the case that you'll simply write it. You will have to refactor the surrounding area in order to do this. Again, this is not hard at all, but it is something extra to think about, which is not related to neither your problem nor your solution of the problem, it is merely a syntactical quirk.

我认为你已经明白了，但就是这种情况。

I think you already get the point, but it would be this scenario.

初始代码：

if(foo) bar();

更改代码：

if(foo) bar(); baz();

您可以清楚地看到问题，但可能不一定会在例行代码审查中弹出。如果您的测试用例没有涵盖这个特定的代码路径，那么由于重复的编码器疏忽，这可能会被推向生产阶段，这可以通过不要求明确分隔块来实现。
您可以采用的解决方案，就像 if（foo）bar（）&& baz（），但是如果 bar（）是假的，那么会失败，所以你最终会遇到像这样丑陋的东西，如果（foo）（bar（），baz（））; 哪个有效，但非常难看。

You can see the problem clearly, but it might not necessarily pop up in a routine code review. If your testcases don't cover this specific codepath, this might get pushed to production because of repeated coder oversights, which are made easier by not requiring blocks be delimited explicitly. The solution you'd could adopt, as you have, is to say something like if(foo) bar() && baz(), but that would fail if bar() is falsy, so you end up with ugly stuff like if(foo) (bar(), baz()); which works, but is decidedly very ugly.

就个人而言，我只使用单行 if 语句，当行非常短时，算法本身也很短。类似 if（extra_loop） - i; 或 if（！valid）break; 当你开始添加 else 对于这些单行ifs，结构变得越来越危险。

Personally, I use single-line if statements solely when the line is very short, and the algorithm itself is short as well. Something like if(extra_loop) --i; or if(!valid) break; When you start adding elses to these single-line ifs, the structure becomes more and more dangerous to manipulate.

简而言之，您可以使用它，但使用它知道利弊，就像任何其他工具一样。

In short, you can use it, but use it knowing the pros and cons, just like any other tool.

这篇关于JSLint支持If-Block的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！