blocks|key|1393850|text|我总是使用第一种方法。更容易阅读，更少的缩进。至于执行速度，这将取决于实现，但我希望它们都是相同的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1393851|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I always go with the first method. Easier to read, and less indentation. As far as execution speed, this will depend on the implementation, but I would expect them both to be identical.

blocks|key|1178538|text|在许多语言中，使用invert+if+statements+to+reduce+nesting或preconditions是一种常见的做法。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1178539|减少代码中的嵌套可以提高代码的可读性和可维护性。|1178540|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/268132/invert-if-statement-to-reduce-nesting|1|http://en.wikipedia.org/wiki/Precondition^0|G|2|9|12|0|1C|D|1|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]]|D|@$9|U|A|V|1|W]|$9|X|A|Y|1|Z]]|E|$]]|$1|F|3|G|5|6|7|10|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|11|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]|P|$5|K|L|M|E|$N|Q]]]]

In many languages, is a common practice to <a href="https://stackoverflow.com/questions/268132/invert-if-statement-to-reduce-nesting">invert <code>if</code> statements to reduce nesting</a> or use <a href="http://en.wikipedia.org/wiki/Precondition" rel="nofollow noreferrer">preconditions</a>.

And having less nesting in your code improves code readability and maintainability.

blocks|key|1393959|text|在性能上不会有任何差异，我推荐第二个例子，以提高可维护性。一般来说，一个例程只有一个可能的出口点是很好的做法。它有助于调试和理解。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1393960|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

There won't be any difference in performance I would recommend the second example for maintainability. In general it's good practice to have one and only one possible exit point for a routine. It aids debugging and comprehension.

blocks|key|1394169|text|在排除无效情况时，我将使用第一种方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1394170|例如：在做一些验证时使用第一种方法，如果任何验证失败，则返回。如果任何一个前提条件都失败了，那么进一步的工作就没有意义了。Martin+fowler在他的Refactoring一书中也提到了同样的事情。他称之为“用Guard条款替换条件”。而且它真的可以让代码更容易理解。|offset|length|1394171|下面是一个java示例。|1394172|++public+void+debitAccount(Account+account,+BigDecimal+amount)+{
++++if(account.user+==+getCurrentUser())+{
++++++if(account.balance+>+amount)+{
+++++++++++account.balance+=+account.balance+-+amount
+++++++}+else+{
++++++++++//return+or+throw+exception
+++++++}
++++}+else+{
++++++++//return+or+throw+exception
++++}
++}|code-block|syntax|javascript|1394173|VS|1394174|+public+void+debitAccount(Account+account,+BigDecimal+amount)+{
++++if(account.user+!=+getCurrentUser())+return+//or+error
++++if(account.balance+<+amount)+return+//or+error
++++account.balance+=+account.balance+-+amount++++
}|1394175|entityMap|0|LINK|mutability|MUTABLE|url|http://martinfowler.com/books/refactoring.html^0|0|25|B|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@$D|10|E|11|1|12]]|A|$]]|$1|F|3|G|5|6|7|13|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|14|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|15|8|@]|9|@]|A|$]]|$1|O|3|P|5|J|7|16|8|@]|9|@]|A|$K|L]]|$1|Q|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|R|$S|$5|T|U|V|A|$W|X]]]]

I will use the first approach when ruling out the invalid situations.

Eg. use first approach when doing some validations, and return if any of the validation fails. There's no point in going further if any of the preconditions fail. The same thing is mentioned by Martin fowler in his <a href="http://martinfowler.com/books/refactoring.html" rel="nofollow">Refactoring</a> book. He calls it "Replacing the conditions with Guard clauses". And it can really make the code easy to understand.

Here's a java example.

<pre><code> public void debitAccount(Account account, BigDecimal amount) {
 if(account.user == getCurrentUser()) {
 if(account.balance &gt; amount) {
 account.balance = account.balance - amount
 } else {
 //return or throw exception
 }
 } else {
 //return or throw exception
 }
 }
</code></pre>

VS

<pre><code> public void debitAccount(Account account, BigDecimal amount) {
 if(account.user != getCurrentUser()) return //or error
 if(account.balance &lt; amount) return //or error
 account.balance = account.balance - amount 
}
</code></pre>

blocks|key|1178496|text|也许有一点，但我不认为它将是可测量的，除非函数的其余部分涉及“繁重的”(否则是多余的，因为我假设返回会产生相同的结果)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1178497|顺便说一句，我认为这是不必要的微优化，你可能应该在其他地方寻找性能改进，例如通过Chrome的开发人员工具或Firebug+for+Firefox+(或类似工具)来分析脚本，并寻找运行缓慢/长时间运行的调用/函数。|1178498|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Maybe slightly, but I don't think it will be measurable unless the rest of the function involves "heavy" (and otherwise redundant since I assume that a return would give same result) js calls.

As a side note, I think this is unnecessary micro optimization, and you should probably look elsewhere for performance improvements, ie profile the script through Chrome's developer tools or Firebug for Firefox (or similar tools) and look for slow/long running calls/functions.

blocks|key|1178581|text|虽然这取决于正在运行的浏览器的JavaScript实现，但它们之间应该没有任何显著的差异(在速度方面)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1178582|第二种形式更可取，因为打破流程不是一个好的编程习惯。还要考虑在汇编中，跳转指令(微操作)总是被求值，而不是求值。|1178583|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

While it depends on the JavaScript implementation of the running browser, there should not be any notable difference between them (in terms of speed).

The second form is preferable since breaking the flow is not a good programming habit. Also think about that in assembly, the jump instruction (micro operation) is always evaluated regardless of the evaluation.

blocks|key|1178675|text|当只有一个if..else+the+performance+is+almost+the+same时，这无关紧要。使用最适合您的情况的可读性最好的内容。但是，与if...else和case+switch相比，使用return实现嵌套语句是一种most+performant|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1178676|entityMap|0|LINK|mutability|MUTABLE|url|https://jsperf.com/if-else-return-vs-not-return|1|https://jsperf.com/if-else-chain-vs-switch-true/12^0|5|8|27|9|2H|B|2X|6|E|Y|0|3C|F|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]|$9|S|A|T|B|C]|$9|U|A|V|B|C]|$9|W|A|X|B|C]]|D|@$9|Y|A|Z|1|10]|$9|11|A|12|1|13]]|E|$]]|$1|F|3|-4|5|6|7|14|8|@]|D|@]|E|$]]]|G|$H|$5|I|J|K|E|$L|M]]|N|$5|I|J|K|E|$L|O]]]]

When there is only a single <code>if..else</code> <a href="https://jsperf.com/if-else-return-vs-not-return" rel="nofollow">the performance is almost the same</a> and it doesn't matter. Use whatever is best readable in your case. But coming to nested statements using <code>return</code> is the <a href="https://jsperf.com/if-else-chain-vs-switch-true/12" rel="nofollow">most performant</a> compared to <code>if...else</code> and <code>case switch</code>

blocks|key|1393882|text|你自己测试一下。如果这个JavaScript是在浏览器中运行的，那么它几乎肯定依赖于浏览器的JavaScript解析引擎。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1393883|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Test it yourself. If this JavaScript is being run in the browser, it will almost certainly depend on the browser's JavaScript parsing engine.

blocks|key|1393937|text|我的理解是，这不会有什么不同，因为您使用if条件进行分支。因此，如果some_condition为true，则else部分将不会被触及，即使没有返回。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1393938|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

My understanding is that would not make a difference because you branch with the if condition. So, if some_condition is true, the else portion will not be touched, even without the return.

blocks|key|1394230|text|在我看来，return和else在上述情况下是相同的，但通常if-else和if()return;是非常不同的。当您想要从当前作用域移动到父作用域时，可以使用Return语句，而对于if-else，您可以在同一作用域中检查进一步的if-else。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1394231|entityMap^0|U|7|12|B|2J|7|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|O|8|@]|D|@]|E|$]]]|G|$]]

In my opinion, return and else is same for the above case but in general <code>if-else</code> and <code>if()return;</code> are very different. You can use return statement when you want to move from the present scope to parent scope while in case of <code>if-else</code> you can check for further if-else in the same scope.

I am working on a project which requires some pretty intricate JavaScript processing. This includes a lot of nested <code>if</code>-<code>else</code>s in quite a few places. I have generally taken care to optimise JavaScript code as much as possible by reading the other tips on Stack&nbsp;Overflow, but I am wondering if the following two constructs would make any difference in terms of speed alone:

<pre><code>if(some_condition) {
 // process
 return ;
}

// Continue the else condition here
</code></pre>

vs

<pre><code>if(some_condition) {
 // Process
}

else {
 // The 'else' condition...
}
</code></pre>

Using 'return' instead of 'else' in JavaScript

我正在从事一个项目，这需要一些相当复杂的JavaScript处理。这包括在相当多的地方嵌套了很多if-else。我通常会通过阅读有关堆栈溢出的其他技巧来尽可能优化JavaScript代码，但我想知道以下两个构造是否仅在速度方面会有所不同：if(some_condition) {    // process    return ;}// Continue the else condition her

问在JavaScript中使用“return”而非“else”
EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在JavaScript中使用“return”而非“else”EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在JavaScript中使用“return”而非“else”
EN