blocks|key|3363622|text|当涉及到性能时，它没有什么有效的区别。因此，在您正在解决的问题的上下文中，我将使用更容易理解的任何一个。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3363623|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|$]]

It makes no effective difference when it comes to performance. Therefore I would use whichever is easier to understand in the context of the problem you are solving.

blocks|key|3363635|text|这两个循环都迭代了7次。我会说里面有7的那个更易读/更清晰，除非你对另一个有很好的理由。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3363636|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|$]]

Both of those loops iterate 7 times. I'd say the one with a 7 in it is more readable/clearer, unless you have a really good reason for the other.

blocks|key|361692|text|在Java1.5中，您可以这样做|type|unstyled|depth|inlineStyleRanges|entityRanges|data|361693|for+(int+i:+myArray)+{
++++...
}|code-block|syntax|javascript|361694|因此，对于数组情况，您无需担心。|361695|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

In Java 1.5 you can just do

<pre><code>for (int i: myArray) {
 ...
}
</code></pre>

so for the array case you don't need to worry.

blocks|key|3363772|text|我总是使用<+array.length-1，因为它比<=+array.length+-1更容易阅读。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3363773|还有<7，并且你知道它是从0索引开始的，那么这个数字就是迭代的次数，这应该是直观的。|3363774|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|$]]

I always use &lt; array.length because it's easier to read than &lt;= array.length-1.

also having &lt; 7 and given that you know it's starting with a 0 index it should be intuitive that the number is the number of iterations.

blocks|key|359627|text|我不认为有性能上的区别。不过，第二种形式的可读性肯定更好，你不需要在脑海中减去1就可以得到最后一个迭代号。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|359628|编辑：我看到其他人不同意。就我个人而言，我喜欢看到循环结构中的实际索引号。也许是因为它更容易让人想起Perl语言的0..6语法，我知道它等同于(0,1,2,3,4,5,6)。如果我看到一个7，我必须检查它旁边的运算符，以查看实际上从未达到索引7。|offset|length|style|BOLD|CODE|359629|entityMap^0|0|0|3|1L|4|1Z|F|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@$D|M|E|N|F|G]|$D|O|E|P|F|H]|$D|Q|E|R|F|H]]|9|@]|A|$]]|$1|I|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|J|$]]

I don't think there is a performance difference. The second form is definitely more readable though, you don't have to mentally subtract one to find the last iteration number.

EDIT: I see others disagree. For me personally, I like to see the actual index numbers in the loop structure. Maybe it's because it's more reminiscent of Perl's <code>0..6</code> syntax, which I know is equivalent to <code>(0,1,2,3,4,5,6)</code>. If I see a 7, I have to check the operator next to it to see that, in fact, index 7 is never reached.

blocks|key|361750|text|我更喜欢：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|361751|for+(int+i+=+0;+i+<+7;+i%2B%2B)|code-block|syntax|javascript|361752|我认为这更容易翻译为“循环迭代7次”。|361753|我不确定性能的影响-我怀疑任何差异都会被编译掉。|361754|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

I prefer:

<pre><code>for (int i = 0; i &lt; 7; i++)
</code></pre>

I think that translates more readily to "iterating through a loop 7 times".

I'm not sure about the performance implications - I suspect any differences would get compiled away.

blocks|key|361758|text|首先是更多的idiomatic。特别是，它指示(从0开始)迭代的次数。当使用基于1的东西(例如JDBC、IIRC)时，我可能会倾向于使用<=。所以：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|361759|for+(int+i=0;+i+<+count;+i%2B%2B)+//+For+0-based+APIs

for+(int+i=1;+i+<=+count;+i%2B%2B)+//+For+1-based+APIs|code-block|syntax|javascript|361760|我希望在现实世界的代码中性能差异是微不足道的。|361761|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wiktionary.org/wiki/idiomatic^0|6|9|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@$A|T|B|U|1|V]]|C|$]]|$1|D|3|E|5|F|7|W|8|@]|9|@]|C|$G|H]]|$1|I|3|J|5|6|7|X|8|@]|9|@]|C|$]]|$1|K|3|-4|5|6|7|Y|8|@]|9|@]|C|$]]]|L|$M|$5|N|O|P|C|$Q|R]]]]

The first is more <a href="http://en.wiktionary.org/wiki/idiomatic" rel="noreferrer">idiomatic</a>. In particular, it indicates (in a 0-based sense) the number of iterations. When using something 1-based (e.g. JDBC, IIRC) I might be tempted to use &lt;=. So:

<pre><code>for (int i=0; i &lt; count; i++) // For 0-based APIs

for (int i=1; i &lt;= count; i++) // For 1-based APIs
</code></pre>

I would expect the performance difference to be insignificantly small in real-world code.

blocks|key|361766|text|我认为两个都可以，但当你选择时，坚持一个或另一个。如果你习惯于使用<=，那么尽量不要使用<，反之亦然。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|361767|我更喜欢<=，但在使用从零开始的索引的情况下，我可能会尝试使用<。不过这完全是个人喜好。|361768|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|$]]

I think either are OK, but when you've chosen, stick to one or the other. If you're used to using &lt;=, then try not to use &lt; and vice versa. 

I prefer &lt;=, but in situations where you're working with indexes which start at zero, I'd probably try and use &lt;. It's all personal preference though.

blocks|key|361005|text|从优化的角度来看，这并不重要。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|361006|从代码风格的角度来看，我更喜欢<。原因：|361007|for+(+int+i+=+0;+i+<+array.size();+i%2B%2B+)|code-block|syntax|javascript|361008|的可读性要比|361009|for+(+int+i+=+0;+i+<=+array.size()+-1;+i%2B%2B+)|361010|也可以直接给出迭代的次数。|361011|对<的另一种投票是，你可以防止许多意外的off-by-one错误。|361012|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

Seen from an optimizing viewpoint it doesn't matter.

Seen from a code style viewpoint I prefer &lt; . Reason:

<pre><code>for ( int i = 0; i &lt; array.size(); i++ )
</code></pre>

is so much more readable than

<pre><code>for ( int i = 0; i &lt;= array.size() -1; i++ )
</code></pre>

also &lt; gives you the number of iterations straight away.

Another vote for &lt; is that you might prevent a lot of accidental off-by-one mistakes.

blocks|key|361783|text|我同意大家所说的7在这种情况下是有意义的，但我想补充说，在6很重要的情况下，假设你想要清楚地表明你只作用于第6个索引以下的对象，那么<=更好，因为它使6更容易看到。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|361784|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 agree with the crowd saying that the 7 makes sense in this case, but I would add that in the case where the 6 is important, say you want to make clear you're only acting on objects up to the 6th index, then the &lt;= is better since it makes the 6 easier to see.

blocks|key|361073|text|回到大学的时候，我记得这两个操作在CPU上的计算时间是相似的。当然，我们讨论的是汇编级的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|361074|然而，如果你在谈论C#或Java，我真的不认为其中一个会比另一个更快，你所获得的几纳秒很可能不值得你引入任何混淆。|361075|就我个人而言，我会从业务实现的角度编写有意义的代码，并确保它易于阅读。|361076|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Way back in college, I remember something about these two operations being similar in compute time on the CPU. Of course, we're talking down at the assembly level.

However, if you're talking C# or Java, I really don't think one is going to be a speed boost over the other, The few nanoseconds you gain are most likely not worth any confusion you introduce.

Personally, I would author the code that makes sense from a business implementation standpoint, and make sure it's easy to read.

blocks|key|364417|text|我建议使用"<+7“版本，因为这是大多数人都会阅读的内容--所以如果人们只是略读你的代码，他们可能会错误地解释它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|364418|我不会担心"<“是否比"<=”更快，只是为了可读性。|364419|如果你确实想要提高速度，请考虑以下几点：|364420|for+(int+i+=+0;+i+<+this->GetCount();+i%2B%2B)
{
++//+Do+something
}|code-block|syntax|javascript|364421|要提高性能，您可以稍微重新安排它，以：|364422|const+int+count+=+this->GetCount();
for+(int+i+=+0;+i+<+count;+%2B%2Bi)
{
++//+Do+something
}|364423|注意从循环中删除了GetCount()+(因为这将在每个循环中被查询)，并将"i%2B%2B“更改为"%2B%2Bi”。|364424|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|U|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|V|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|X|8|@]|9|@]|A|$I|J]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

I'd say use the "&lt; 7" version because that's what the majority of people will read - so if people are skim reading your code, they might interpret it wrongly.

I wouldn't worry about whether "&lt;" is quicker than "&lt;=", just go for readability.

If you do want to go for a speed increase, consider the following:

<pre><code>for (int i = 0; i &lt; this-&gt;GetCount(); i++)
{
 // Do something
}
</code></pre>

To increase performance you can slightly rearrange it to:

<pre><code>const int count = this-&gt;GetCount();
for (int i = 0; i &lt; count; ++i)
{
 // Do something
}
</code></pre>

Notice the removal of GetCount() from the loop (because that will be queried in every loop) and the change of "i++" to "++i".

blocks|key|3151253|text|严格地从逻辑的角度来看，您必须认为<+count将比<=+count更有效，因为<=也将测试等价性。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3151254|entityMap^0|H|7|Q|8|14|2|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|$]]

Strictly from a logical point of view, you have to think that <code>&lt; count</code> would be more efficient than <code>&lt;= count</code> for the exact reason that <code>&lt;=</code> will be testing for equality as well.

blocks|key|3151256|text|顺便说一句，当循环访问.Net中的数组或其他集合时，我发现|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3151257|foreach+(string+item+in+myarray)
{
++++System.Console.WriteLine(item);
}|code-block|syntax|javascript|3151258|比数字for循环更具可读性。当然，这是假设循环代码中没有使用实际的计数器Int本身。我不知道是否有性能变化。|3151259|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

As a slight aside, when looping through an array or other collection in .Net, I find

<pre><code>foreach (string item in myarray)
{
 System.Console.WriteLine(item);
}
</code></pre>

to be more readable than the numeric for loop. This of course assumes that the actual counter Int itself isn't used in the loop code. I do not know if there is a performance change.

blocks|key|3151284|text|编写i<7有很多很好的理由，在循环中使用数字7来迭代7次是很好的。性能实际上是相同的。几乎每个人都在写i<7，如果你是为了可读性而写的，那就使用每个人都能马上识别的格式。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3151285|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 are many good reasons for writing i&lt;7. Having the number 7 in a loop that iterates 7 times is good. The performance is effectively identical. Almost everybody writes i&lt;7. If you're writing for readability, use the form that everyone will recognise instantly.

blocks|key|361143|text|我记得我在大学里做8086汇编的时候，做起来更有效率：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|361144|for+(int+i+=+6;+i+>+-1;+i--)|code-block|syntax|javascript|361145|因为有一个JNS操作，这意味着如果没有符号就跳转。使用这种方法意味着在每个周期之后不需要查找内存来获得比较值，也不需要进行比较。如今，大多数编译器都会优化寄存器的使用，所以内存问题不再重要，但你仍然会得到一个不必要的比较。|offset|length|361146|顺便说一下，将7或6放入你的循环中就是引入了一个"magic+number“。为了更好的可读性，你应该使用一个常量和一个能揭示意图的名字。如下所示：|361147|const+int+NUMBER_OF_CARS+=+7;
for+(int+i+=+0;+i+<+NUMBER_OF_CARS;+i%2B%2B)|361148|编辑:人们没有得到组装的东西，所以显然需要一个更完整的例子：|361149|如果我们使用(i+=+0；i+<=+10；i%2B%2B)，你需要这样做：|361150|++++mov+esi,+0
loopStartLabel:
++++++++++++++++;+Do+some+stuff
++++inc+esi
++++++++++++++++;+Note+cmp+command+on+next+line
++++cmp+esi,+10
++++jle+exitLoopLabel
++++jmp+loopStartLabel
exitLoopLabel:|361151|如果我们这样做(int+i=+10；i>+-1；i--)，那么你可以这样做：|361152|++++mov+esi,+10
loopStartLabel:
++++++++++++++++;+Do+some+stuff
++++dec+esi
++++++++++++++++;+Note+no+cmp+command+on+next+line
++++jns+exitLoopLabel
++++jmp+loopStartLabel
exitLoopLabel:|361153|我刚刚检查了一下，微软的C%2B%2B编译器不会做这种优化，但如果你做了，它就会做：|361154|for+(int+i+=+10;+i+>=+0;+i--)+|361155|因此，如果你使用的是微软的C%2B%2B†，升序或降序都没有区别，为了得到一个快速循环，你应该使用：|361156|for+(int+i+=+10;+i+>=+0;+i--)|361157|而不是这两个：|361158|for+(int+i+=+10;+i+>+-1;+i--)
for+(int+i+=+0;+i+<=+10;+i%2B%2B)|361159|但坦率地说，获得"for+(int+=+0；I+<=+10；i%2B%2B)“的可读性通常比缺少一个处理器命令重要得多。|361160|†其他编译器可能会做不同的事情。|361161|entityMap|0|LINK|mutability|MUTABLE|url|http://tic01.tic.ec-lyon.fr/~muller/trotek/cours/8086/JNS.html.en|1|http://en.wikipedia.org/wiki/Magic_number_(programming))^0|0|0|5|3|0|0|P|C|1|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|1P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|1Q|8|@]|9|@$I|1R|J|1S|1|1T]]|A|$]]|$1|K|3|L|5|6|7|1U|8|@]|9|@$I|1V|J|1W|1|1X]]|A|$]]|$1|M|3|N|5|D|7|1Y|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|20|8|@]|9|@]|A|$]]|$1|S|3|T|5|D|7|21|8|@]|9|@]|A|$E|F]]|$1|U|3|V|5|6|7|22|8|@]|9|@]|A|$]]|$1|W|3|X|5|D|7|23|8|@]|9|@]|A|$E|F]]|$1|Y|3|Z|5|6|7|24|8|@]|9|@]|A|$]]|$1|10|3|11|5|D|7|25|8|@]|9|@]|A|$E|F]]|$1|12|3|13|5|6|7|26|8|@]|9|@]|A|$]]|$1|14|3|15|5|D|7|27|8|@]|9|@]|A|$E|F]]|$1|16|3|17|5|6|7|28|8|@]|9|@]|A|$]]|$1|18|3|19|5|D|7|29|8|@]|9|@]|A|$E|F]]|$1|1A|3|1B|5|6|7|2A|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|2B|8|@]|9|@]|A|$]]|$1|1E|3|-4|5|6|7|2C|8|@]|9|@]|A|$]]]|1F|$1G|$5|1H|1I|1J|A|$1K|1L]]|1M|$5|1H|1I|1J|A|$1K|1N]]]]

I remember from my days when we did 8086 Assembly at college it was more performant to do:

<pre><code>for (int i = 6; i &gt; -1; i--)
</code></pre>

as there was a <a href="http://tic01.tic.ec-lyon.fr/~muller/trotek/cours/8086/JNS.html.en" rel="noreferrer">JNS</a> operation that means Jump if No Sign. Using this meant that there was no memory lookup after each cycle to get the comparison value and no compare either. These days most compilers optimize register usage so the memory thing is no longer important, but you still get an un-required compare.

By the way putting 7 or 6 in your loop is introducing a "<a href="http://en.wikipedia.org/wiki/Magic_number_(programming)" rel="noreferrer">magic number</a>". For better readability you should use a constant with an Intent Revealing Name. Like this:

<pre><code>const int NUMBER_OF_CARS = 7;
for (int i = 0; i &lt; NUMBER_OF_CARS; i++)
</code></pre>

EDIT: People aren’t getting the assembly thing so a fuller example is obviously required:

If we do for (i = 0; i &lt;= 10; i++) you need to do this:

<pre><code> mov esi, 0
loopStartLabel:
 ; Do some stuff
 inc esi
 ; Note cmp command on next line
 cmp esi, 10
 jle exitLoopLabel
 jmp loopStartLabel
exitLoopLabel:
</code></pre>

If we do for (int i = 10; i > -1; i--) then you can get away with this:

<pre><code> mov esi, 10
loopStartLabel:
 ; Do some stuff
 dec esi
 ; Note no cmp command on next line
 jns exitLoopLabel
 jmp loopStartLabel
exitLoopLabel:
</code></pre>

I just checked and Microsoft's C++ compiler does not do this optimization, but it does if you do:

<pre><code>for (int i = 10; i &gt;= 0; i--) 
</code></pre>

So the moral is if you are using Microsoft C++†, and ascending or descending makes no difference, to get a quick loop you should use:

<pre><code>for (int i = 10; i &gt;= 0; i--)
</code></pre>

rather than either of these:

<pre><code>for (int i = 10; i &gt; -1; i--)
for (int i = 0; i &lt;= 10; i++)
</code></pre>

But frankly getting the readability of "for (int i = 0; i &lt;= 10; i++)" is normally far more important than missing one processor command.

† Other compilers may do different things.

blocks|key|3364272|text|我一直倾向于：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3364273|for+(+int+count+=+7+;+count+>+0+;+--+count+)|code-block|syntax|javascript|3364274|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

I have always preferred:

<pre><code>for ( int count = 7 ; count &gt; 0 ; -- count )
</code></pre>

blocks|key|359903|text|至少与x86编译器在性能上不应该存在差异。据我所知，JL和JLE可以同时工作。至于可重写性，对于七个元素的数组使用"<7“是有意义的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|359904|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|$]]

It should not be difference in perfomance at least with the x86 compilers. JL and JLE works the same time, as soon as I know. And as for redability, using "&lt;7" for an array of seven elements makes sense.

blocks|key|361933|text|我遵循第一种方法，因为这个习语经常被重复。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|361934|对于(int+index+=+0；index+<+array.length；i%2B%2B)|361935|String+s=+oldString.substring(0，numChars)；|361936|等。|361937|我习惯了上限被排除在外，除非有充分的理由改变它，否则我更愿意保持这种上限。(示例--基于1的索引)|361938|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

I follow the first method as that idiom is repeated frequently.

for (int index = 0; index &lt; array.length; i++)

String s = oldString.substring(0, numChars);

etc. 

I'm used to the upper bound being excluded, and would prefer to keep it that way unless there is good reason to change it. (example -- 1 based indexing)

blocks|key|3151360|text|首先考虑可读性，然后再优化(尽管，老实说，我想不出有什么明显的区别)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3151361|请注意，0+->+K形式是一种C语言习惯用法，通过使数组以0为基数延续到C#中。遵循成语，不要违反最小惊讶原则。|3151362|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|$]]

Go for readability first, optimize later (although, quite honestly, I can't imagine any difference that would be noticeable).

Be aware that the 0 -> K form is a C idiom carried over into C# by having arrays be 0 based. Follow the idiom and don't violate the principal of least astonishment.

blocks|key|3364288|text|您也可以改用!=。这样，如果您在初始化过程中犯了错误，您将得到一个无限循环，从而导致错误更早地被注意到，并且它导致的任何问题都被限制在循环中(而不是在很长时间之后才有问题并找不到它)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3364289|entityMap^0|6|2|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

You could also use <code>!=</code> instead. That way, you'll get an infinite loop if you make an error in initialization, causing the error to be noticed earlier and any problems it causes to be limitted to getting stuck in the loop (rather than having a problem much later and not finding it).

blocks|key|364489|text|首先，不要使用6或7。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|364490|更好地使用：|364491|int+numberOfDays+=+7;
for+(int+day+=+0;+day+<+numberOfDays+;+day%2B%2B){

}|code-block|syntax|javascript|364492|在这种情况下，它比使用|364493|for+(int+day+=+0;+day+<=+numberOfDays++-+1;+day%2B%2B){

}|364494|更好的(Java+/+C#)：|364495|for(int+day+=+0;+day+<+dayArray.Length;+i%2B%2B){

}|364496|甚至更好(C#)|364497|foreach+(int+day+in+days){//+day+:+days+in+Java

}|364498|反向循环确实更快，但由于它更难阅读(如果不是由其他程序员)，最好避免使用。尤其是在C#，Java...|364499|entityMap^0|0|0|0|0|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|@]|A|$]]|$1|D|3|E|5|F|7|10|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|11|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|12|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|13|8|@]|9|@]|A|$]]|$1|O|3|P|5|F|7|14|8|@]|9|@]|A|$G|H]]|$1|Q|3|R|5|6|7|15|8|@]|9|@]|A|$]]|$1|S|3|T|5|F|7|16|8|@]|9|@]|A|$G|H]]|$1|U|3|V|5|6|7|17|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|X|$]]

First, don't use 6 or 7.

Better to use:

<pre><code>int numberOfDays = 7;
for (int day = 0; day &lt; numberOfDays ; day++){

}
</code></pre>

In this case it's better than using

<pre><code>for (int day = 0; day &lt;= numberOfDays - 1; day++){

}
</code></pre>

Even better (Java / C#):

<pre><code>for(int day = 0; day &lt; dayArray.Length; i++){

}
</code></pre>

And even better (C#)

<pre><code>foreach (int day in days){// day : days in Java

}
</code></pre>

The reverse loop is indeed faster but since it's harder to read (if not by you by other programmers), it's better to avoid in. Especially in C#, Java...

blocks|key|3364299|text|养成使用<的习惯将使您和读者在迭代数组时保持一致。对于每个人来说，有一个标准的约定会更简单。如果您使用的是基于0的数组的语言，则<是惯例。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3364300|这几乎肯定比<和<=之间的任何性能差异更重要。首先致力于功能性和可读性，然后再优化。|3364301|另一个需要注意的是，最好是使用%2B%2Bi而不是i%2B%2B，因为fetch和increment需要临时and增量，而fetch不需要。对于整数，你的编译器可能会优化临时离开，但如果你的迭代类型更复杂，它可能无法做到。|3364302|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Making a habit of using &lt; will make it consistent for both you and the reader when you are iterating through an array. It will be simpler for everyone to have a standard convention. And if you're using a language with 0-based arrays, then &lt; is the convention.

This almost certainly matters more than any performance difference between &lt; and &lt;=. Aim for functionality and readability first, then optimize.

Another note is that it would be better to be in the habit of doing ++i rather than i++, since fetch and increment requires a temporary and increment and fetch does not. For integers, your compiler will probably optimize the temporary away, but if your iterating type is more complex, it might not be able to.

blocks|key|3151378|text|不要使用魔术数字。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3151379|为什么是7？(或者是6)。|3151380|请为您要使用的数字使用正确的符号...|3151381|在这种情况下，我认为最好使用|3151382|for+(+int+i+=+0;+i+<+array.size();+i%2B%2B+)|code-block|syntax|javascript|3151383|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Q|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|R|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|S|8|@]|9|@]|A|$K|L]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

Don't use magic numbers.

Why is it 7? ( or 6 for that matter).

use the correct symbol for the number you want to use...

In which case I think it is better to use

<pre><code>for ( int i = 0; i &lt; array.size(); i++ )
</code></pre>

blocks|key|361201|text|在C%2B%2B中，我更喜欢使用!=，它可以用于所有的STL容器。并不是所有的STL容器迭代器都是小于可比的。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|361202|entityMap^0|C|2|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

In C++, I prefer using <code>!=</code>, which is usable with all STL containers. Not all STL container iterators are less-than comparable.

blocks|key|3364334|text|“<”和“<=”运算符的性能成本完全相同。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3364335|“<”运算符是一个标准的运算符，在从零开始的循环中更容易读取。|3364336|在C%2B%2B中使用%2B%2Bi而不是i%2B%2B可以提高性能，但在C#中并不是这样--我不太了解Java。|3364337|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

The '&lt;' and '&lt;=' operators are exactly the same performance cost.

The '&lt;' operator is a standard and easier to read in a zero-based loop.

Using ++i instead of i++ improves performance in C++, but not in C# - I don't know about Java.

blocks|key|3151448|text|我更喜欢这样：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3151449|for+(int+i+=+0;+i+<+7;+i%2B%2B)|code-block|syntax|javascript|3151450|然而(这只是一个想法)，它的可读性可能取决于数组是从0开始(C#，Java)还是从1开始(VB+.NET)。我这么说是因为当你使用基于0的数组时，你会产生一种思维方式，认为0-6会运行7次。我认为0-6比1-7更直观。话又说回来，我来自C%2B%2B，Java，C#背景。|3151451|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

I prefer this:

<pre><code>for (int i = 0; i &lt; 7; i++)
</code></pre>

However (this is merely a thought), the readability of it might have to do whether or not arrays are 0-based (C#, Java) or 1-based (VB .NET). I say this because when you work with 0-based arrays, you get in a mindset that 0-6 would run 7 times. I think 0-6 is more intuitive than 1-7. Then again, I come from a C++, Java, C# background.

blocks|key|3151493|text|对于某些语言/技术，如使用.Size或.Length或size()的.NET，/length()不是一个好主意，因为它在每次迭代时都会访问该属性，因此将其赋给变量对性能的影响较小。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3151494|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|$]]

For some languages/technologies like .NET using .Size or .Length or size()/length() is a bad idea is it accesses that property each time it iterates, so assigned it to a variable has a slightly less performance hit.

blocks|key|3151509|text|正如人们所观察到的，你提到的两种选择中的任何一种都没有区别。为了确认这一点，我在JavaScript中做了一些简单的基准测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3151510|您可以查看结果here。不清楚的是，如果我交换了第一个和第二个测试的位置，这两个测试的结果交换了，这显然是一个内存问题。然而，第三次测试中，我颠倒了迭代的顺序，显然更快。|offset|length|3151511|entityMap|0|LINK|mutability|MUTABLE|url|http://unitorganizer.com/javascript/loops/^0|0|7|4|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

As people have observed, there is no difference in either of the two alternatives you mentioned. Just to confirm this, I did some simple benchmarking in JavaScript.

You can see the results <a href="http://unitorganizer.com/javascript/loops/" rel="nofollow noreferrer">here</a>. What is not clear from this is that if I swap the position of the 1st and 2nd tests, the results for those 2 tests swap, this is clearly a memory issue. However the 3rd test, one where I reverse the order of the iteration is clearly faster.

blocks|key|361286|text|@Chris，你关于.Length在.NET中开销很大的说法实际上是不正确的，在简单类型的情况下恰好相反。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|361287|int+len+=+somearray.Length;
for(i+=+0;+i+<+len;+i%2B%2B)
{
++somearray[i].something();
}|code-block|syntax|javascript|361288|实际上比|361289|for(i+=+0;+i+<+somearray.Length;+i%2B%2B)
{
++somearray[i].something();
}|361290|后者是由运行时优化的一种情况。由于运行库可以保证i是数组中的有效索引，因此不会执行任何边界检查。在前者中，运行时不能保证我在循环之前没有被修改，并强制在每次索引查找时对数组进行边界检查。|361291|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

@Chris, Your statement about .Length being costly in .NET is actually untrue and in the case of simple types the exact opposite.

<pre><code>int len = somearray.Length;
for(i = 0; i &lt; len; i++)
{
 somearray[i].something();
}
</code></pre>

is actually slower than

<pre><code>for(i = 0; i &lt; somearray.Length; i++)
{
 somearray[i].something();
}
</code></pre>

The later is a case that is optimized by the runtime. Since the runtime can guarantee i is a valid index into the array no bounds checks are done. In the former, the runtime can't guarantee that i wasn't modified prior to the loop and forces bounds checks on the array for every index lookup.

blocks|key|3151576|text|正如每个人都说的，习惯上使用0索引迭代器，即使是数组之外的东西也是如此。如果一切都以0开始，以n-1结束，并且下限始终为<=，上界始终为<，那么在审查代码时，您需要考虑的事情就会少得多。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3151577|entityMap^0|16|1|1B|3|1O|2|1W|1|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]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|G|$]]

As everybody says, it is customary to use 0-indexed iterators even for things outside of arrays. If everything begins at <code>0</code> and ends at <code>n-1</code>, and lower-bounds are always <code>&lt;=</code> and upper-bounds are always <code>&lt;</code>, there's that much less thinking that you have to do when reviewing the code.

blocks|key|360042|text|结果是没有意义的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|360043|从硬件的角度来看，具有loopNumber-1的<=将在每次迭代中引入一个额外的计算来执行loopNumber-1。因此，我假设<将花费更少的时间，如果不是与<=相同的时间|360044|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|$]]

The results doesn't make sense.

From a hardware point of view, &lt;= with a loopNuumber-1 will introduce one extra calculation to do loopNumber-1 per iteration. So I assume that &lt; will take less time, if not same amount of time than &lt;=

blocks|key|361361|text|这直接属于"Making+Wrong+Code+Look+Wrong"类别。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|361362|在基于零的索引语言中，例如Java或C#，人们习惯于index+<+count条件的变化。因此，利用这一事实上的约定将使off-by-one错误更加明显。|style|CODE|361363|关于性能:任何值得占用内存的好编译器都应该渲染为无问题的。|361364|entityMap|0|LINK|mutability|MUTABLE|url|http://www.joelonsoftware.com/articles/Wrong.html^0|5|U|0|0|Q|D|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@$A|W|B|X|F|G]]|9|@]|C|$]]|$1|H|3|I|5|6|7|Y|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|Z|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]]]

This falls directly under the category of <a href="http://www.joelonsoftware.com/articles/Wrong.html" rel="nofollow noreferrer">"Making Wrong Code Look Wrong"</a>. 

In zero-based indexing languages, such as Java or C# people are accustomed to variations on the <code>index &lt; count</code> condition. Thus, leveraging this defacto convention would make off-by-one errors more obvious.

Regarding performance: any good compiler worth its memory footprint should render such as a non-issue.

blocks|key|3364532|text|Edsger+Dijkstra+wrote+an+article早在1982年就提出了这一观点，当时他主张降低<=+I<+upper：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3364533|3364534|有一个最小的自然数。b)和d)中的下界-as的排除-强制从最小自然数开始的子序列，如上所述，下界进入非自然数的领域。这很难看，所以对于下界，我们更喜欢a)和c)中的≤。现在考虑从最小自然数开始的子序列:包含上界将迫使后者在序列缩小到空数时变得不自然。这是丑陋的，所以对于上限，我们更喜欢<如a)和d)。我们得出结论，约定a)是首选的。|blockquote|3364535|3364536|entityMap|0|LINK|mutability|MUTABLE|url|http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html^0|G|G|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|V|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|W|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|J|$K|$5|L|M|N|C|$O|P]]]]

Edsger Dijkstra <a href="http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html" rel="nofollow noreferrer">wrote an article</a> on this back in 1982 where he argues for lower &lt;= i &lt; upper:

<blockquote>
 There is a smallest natural number. Exclusion of the lower bound —as in b) and d)— forces for a subsequence starting at the smallest natural number the lower bound as mentioned into the realm of the unnatural numbers. That is ugly, so for the lower bound we prefer the ≤ as in a) and c). Consider now the subsequences starting at the smallest natural number: inclusion of the upper bound would then force the latter to be unnatural by the time the sequence has shrunk to the empty one. That is ugly, so for the upper bound we prefer &lt; as in a) and d). We conclude that convention a) is to be preferred.
</blockquote>

blocks|key|3364554|text|过早优化是万恶之源。使用可读性，除非有很好的理由担心<胜过<=。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3364555|entityMap^0|Q|1|T|2|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

Premature optimization is the root of all evil. Go with readability unless there is a really good reason to worry about <code>&lt;</code> over <code>&lt;=</code>.

blocks|key|3364575|text|没有速度差异，但在使用基于0的数组的语言中，<更可能是正确的。同样，如果你想向下迭代而不是向上迭代，你可以说：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3364576|for+(i+=+7;+--i+>=+0;+)+...|code-block|syntax|javascript|3364577|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

No speed difference, but &lt; is more likely to be correct in a language with 0-based arrays. Also, if you want to iterate down instead of up, you can say:

<pre><code>for (i = 7; --i &gt;= 0; ) ...
</code></pre>

blocks|key|3364591|text|我认为它应该是<。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3364592|几个词就可以了，为什么还要用这么多词呢？一个测试比两个测试更容易理解。因此，单元测试和修改将变得更容易。|3364593|差别很小吗？是。但是，为什么要在不必要的情况下增加复杂性呢？|3364594|最后，在开始优化代码时，您不需要依赖任何优化器或解释器实现。引用爱因斯坦的话说，“尽量保持简单，但不要简单”。|3364595|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I would argue it should be &lt;. 

Why use many words when a few will do. One test is easier to understand then two. Consquently, it is easier to unit test and modify going forward. 

Is the difference small? Yes. But why add any complexity when it is not warranted. 

Finally, you are not reliant on any optimizer or implementation of an interpreter when the code is optimized to begin with. To quote Einstein, "keep it as simple as possible but no simpler".

blocks|key|362114|text|问得好。我的答案是:使用类型A+('<')|type|unstyled|depth|inlineStyleRanges|entityRanges|data|362115|362116|你可以清楚地看到你有多少次迭代(7)。|unordered-list-item|362117|两个端点之间的区别在于范围的宽度|362118|使其更具可读性|362119|您拥有的元素总数通常是i+<+strlen(s)，而不是最后一个元素的索引，因此一致性很重要。|offset|length|style|CODE|362120|362121|另一个问题是整个构造。i在其中出现了3次，所以它可能会输入错误。for循环结构告诉我们如何做，而不是what+to+do。我建议采用这一点：|BOLD|362122|BOOST_FOREACH(i,+IntegerInterval(0,7))|362123|这是更清楚，编译成完全相同的汇编语言的指令，等。向我要IntegerInterval的代码，如果你喜欢。|362124|entityMap^0|0|0|0|0|0|B|D|0|0|B|1|1E|A|0|0|12|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|10|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|11|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|12|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|13|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|14|8|@$L|15|M|16|N|O]]|9|@]|A|$]]|$1|P|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|18|8|@$L|19|M|1A|N|O]|$L|1B|M|1C|N|S]]|9|@]|A|$]]|$1|T|3|U|5|6|7|1D|8|@$L|1E|M|1F|N|O]]|9|@]|A|$]]|$1|V|3|W|5|6|7|1G|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]]|Y|$]]

Great question. My answer: use type A ('&lt;')

<ul>
<li>You clearly see how many iterations you have (7). </li>
<li>The difference between two endpoints is the width of the range</li>
<li>Less characters makes it more readable</li>
<li>You more often have the total number of elements <code>i &lt; strlen(s)</code> rather than the index of the last element so uniformity is important.</li>
</ul>

Another problem is with this whole construct. <code>i</code> appears 3 times in it, so it can be mistyped. The for-loop construct says how to do instead of what to do. I suggest adopting this:

<code>BOOST_FOREACH(i, IntegerInterval(0,7))</code>

This is more clear, compiles to exaclty the same asm instructions, etc. Ask me for the code of IntegerInterval if you like.

blocks|key|3364644|text|答案太多了。但我想我还有什么要补充的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3364645|我的偏好是让文字数字清楚地向显示"i“将在循环中取什么值。因此，在迭代从零开始的数组的情况下：|offset|length|style|BOLD|3364646|for+(int+i+=+0;+i+<=+array.Length+-+1;+%2B%2Bi)|CODE|3364647|如果你只是循环，而不是迭代数组，从1数到7是非常直观的：|3364648|for+(int+i+=+1;+i+<=+7;+%2B%2Bi)|3364649|在你分析它之前，可读性胜过性能，因为在那之前你可能不知道编译器或运行时会对你的代码做什么。|3364650|entityMap^0|0|E|9|0|0|17|0|0|0|S|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@$D|U|E|V|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|W|8|@$D|X|E|Y|F|J]]|9|@]|A|$]]|$1|K|3|L|5|6|7|Z|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|10|8|@$D|11|E|12|F|J]]|9|@]|A|$]]|$1|O|3|P|5|6|7|13|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|R|$]]

So many answers ... but I believe I have something to add.

My preference is for the literal numbers to clearly show what values "i" will take in the loop. So in the case of iterating though a zero-based array:

<code>for (int i = 0; i &lt;= array.Length - 1; ++i)</code>

And if you're just looping, not iterating through an array, counting from 1 to 7 is pretty intuitive:

<code>for (int i = 1; i &lt;= 7; ++i)</code>

Readability trumps performance until you profile it, as you probably don't know what the compiler or runtime is going to do with your code until then.

If you had to iterate through a loop 7 times, would you use:

<pre><code>for (int i = 0; i &lt; 7; i++)
</code></pre>

or:

<pre><code>for (int i = 0; i &lt;= 6; i++)
</code></pre>

There are two considerations:

<ul>
<li>performance</li>
<li>readability </li>
</ul>

For performance I'm assuming Java or C#. Does it matter if "less than" or "less than or equal to" is used? If you have insight for a different language, please indicate which.

For readability I'm assuming 0-based arrays.

UPD: My mention of 0-based arrays may have confused things. I'm not talking about iterating through array elements. Just a general loop. 

There is a good point below about using a constant to which would explain what this magic number is. So if I had "<code>int NUMBER_OF_THINGS = 7</code>" then "<code>i &lt;= NUMBER_OF_THINGS - 1</code>" would look weird, wouldn't it.

Should one use < or <= in a for loop

单元测试

编译器

解释器

容器

Java

Perl

如果你不得不遍历一个循环7次，你会使用：for (int i = 0; i < 7; i++)或者：for (int i = 0; i <= 6; i++)有两个考虑因素：performancereadability 为了提高性能，我假设使用Java或C#。使用“小于”或“小于或等于”有关系吗？如果您对不同的语言有洞察...

问是否应该在for循环中使用<或<=
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问是否应该在for循环中使用<或<=EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问是否应该在for循环中使用<或<=
EN