'<'与'！='作为'for'循环中的条件？

假设您有以下for循环*：

for (int i = 0; i < 10; ++i) {
    // ...
}

通常也可以写成：

for (int i = 0; i != 10; ++i) {
    // ...
}

最终结果是相同的，因此是否有真正的论据来使用一个？我个人使用前者，以防万一i由于某种原因而陷入混乱，并跳过了值10。

_{*对不起幻数的用法，但这只是一个例子。}

选择一个或另一个的原因是出于意图，因此，它增加了可读性。

目的：循环的运行时间应i小于10，而不是i不等于10。即使在特定情况下后者可能相同，也并非您的意思，因此不应这样写。

可读性：写下您的意思的结果是它也更易于理解。例如，如果您使用i != 10，则读取代码的人可能会怀疑循环内部是否有某种方法i可能会变得大于10，并且循环应该继续（顺便说一句：在迭代器的头部以外的地方与迭代器打交道是很糟糕的样式） - for语句，但这并不意味着人们不这样做，因此维护人员期望它）。

<即使增量恰好不是1，该模式通常也可用。

这允许执行循环的单一通用方法，而不管其实际执行方式如何。

在C ++中，斯科特·迈尔斯（Scott Myers）在“更有效的C ++”（项目6）中的建议始终使用第二个，除非您有理由不这样做，因为这意味着您对迭代器和整数索引具有相同的语法，因此可以在int和迭代器之间无缝交换语法没有任何变化。

在其他语言中，这并不适用，因此我想<可能是可取的，因为ThorbjørnRavn Andersen的观点。

顺便说，有一天，我与另一位开发人员讨论这个，他说喜欢的原因<了!=，因为i可能会意外地被一个以上的增加，以及可能导致中断条件未得到满足; 那是IMO的废话。

我认为使用（i <10）是更安全的做法。它捕获了潜在的退出案例的最大数量-大于或等于10的所有案例。将其与其他案例进行对比（i = 10）；当我刚好是10岁时，它只会遇到一个可能的退出案例。

这样做的副产品是提高了可读性。另外，如果增量为其他1，则当我们在编写退出案例时出错时，可以帮助最小化问题的可能性。

考虑：

1) for (i = 1; i < 14; i+=2)

2) for (i = 1; i != 14; i+=2)

尽管这两种情况都可能有缺陷/错误，但是第二种错误可能更多，因为它不会退出。第一种情况会退出，即使有14个错误的数字（在15个可能更好），也有可能在正确的位置退出。

这是另一个似乎没有人提出的答案。 for当需要迭代序列时，应使用循环。使用!=是陈述循环终止条件的最简洁的方法。但是，使用限制性较小的运算符是非常常见的防御性编程习惯。对于整数没有关系-这只是个人选择，没有更具体的示例。!=出于其他人陈述的原因，使用要使用的迭代器循环遍历集合。如果考虑float或的序列double，那么您将!=不惜一切代价避免。

我想指出的是，for当您需要遍历序列时使用。生成的序列具有起点，间隔和终止条件。这些在for声明中简明地指定。如果您发现自己（1）不包括的步骤部分，for或者（2）指定了类似true保护条件的内容，那么您不应该使用for循环！

该while循环用于在特定的条件满足时继续处理。 如果不处理序列，则可能需要while循环。保护条件参数在这里是相似的，但是在a while和for循环之间的决定应该是一个非常有意识的决定。while在C ++圈子IMO中，该循环未被充分认识。

如果您正在处理项目的集合（非常常见的for-loop用法），那么您确实应该使用更专业的方法。不幸的是，std::for_each由于多种原因，在C ++中非常痛苦。在许多情况下，以for独立功能（虽然有些痛苦）将环路的主体分开会导致更清洁的解决方案。 当使用集合，考虑std::for_each，std::transform或std::accumulate。 以这种方式表达时，许多算法的实现变得简洁明了。更不用说将循环主体隔离为单独的函数/方法会迫使您专注于算法，算法的输入要求和结果。

如果您使用的是Java，Python，Ruby甚至C ++ 0x，则应该使用适当的foreach循环集合。随着C ++编译器实现此功能，for这些类型的讨论将消失许多循环。

使用“小于”在语义上通常是正确的，实际上，您的意思是直到i不小于10 为止，因此“小于”清楚地传达了您的意图。使用“不等于”显然可以在虚拟调用情况下使用，但传达的含义略有不同。在某些情况下，这可能是您所需要的，但根据我的经验，从来没有这样。如果确实有一个i可能大于或小于10 的情况，但您想一直循环直到等于10，那么该代码确实需要非常清楚地注释，并且可能可以使用其他一些结构更好地编写，例如作为一个while循环。

我之所以支持a而less than不是a的原因之一not equals是充当后卫。在某些有限的情况下（不良的编程或消毒），not equals可以跳过，而less than仍然有效。

这是一个缺少消毒检查导致奇怪结果的示例：http : //www.michaeleisen.org/blog/? p=358

这是您可能更喜欢使用<而不是的原因之一!=。如果您使用的语言具有全局变量作用域，那么如果修改其他代码会i怎样？如果您使用<而不是!=，则发生的最坏情况是迭代完成得更快：也许其他一些代码i偶然增加了，您在for循环中跳过了几次迭代。但是，如果您从0到10循环，而循环达到9，又i由于某些奇怪的原因，一些写入不良的线程增量会发生什么。然后，循环完成该迭代并递增，i以使该值现在为11。由于循环已跳过退出条件（i从不等于10），因此它将无限循环。

导致这种情况的不一定是特别怪异的线程化和全局变量类型逻辑。可能只是您正在编写需要回溯的循环。如果您要i在循环内部进行变异，并且弄乱了逻辑，那么逻辑就应该具有上限而不是a，这样!=就不太可能使您陷入无限循环。

在嵌入式世界中，尤其是在嘈杂的环境中，您不能指望RAM的运行方式必须正确。在使用“ ==”或“！=”进行比较的条件（有条件的情况下）中，您总是冒着变量跳过终止循环的关键值的风险-这可能会带来灾难性后果——Mars Lander水平的后果。在这种情况下使用“ <”或“>”可提供更高的安全性，以捕获“未知未知数”。

在原始示例中，如果i莫名其妙地将其弹射到大于10的值，则'<'比较将立即捕获错误并退出循环，但是'！='将继续向上计数，直到i包裹在0之前并返回至10