'<' против '! =' как условие в цикле '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-statement, но это не означает , что люди не делают этого , и в результате сопровождающие ожидают его).

<Картина , как правило , работает даже если приращение происходит не быть 1 точно.

Это позволяет использовать один общий способ выполнения циклов независимо от того, как это делается на самом деле.

В C ++ рекомендация Скотта Майерса в «Более эффективном C ++» (пункт 6) всегда заключается в использовании второго, если только у вас нет для этого причин, потому что это означает, что у вас одинаковый синтаксис для итерационных и целочисленных индексов, поэтому вы можете легко переключаться между intитератором без каких-либо изменений в синтаксисе.

На других языках это не применимо, так что я думаю, что <это, вероятно, предпочтительнее из-за мнения Торбьерна Равна Андерсена.

Кстати, на днях я обсуждал это с другим разработчиком , и он сказал , что причина предпочесть <более !=потому , что 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 ++ ИМА.

Если вы обрабатываете коллекцию элементов (очень распространенное 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петля возможно.

Одна из причин , почему я выступает за less thanбольше not equals, чтобы действовать в качестве охранника. В некоторых ограниченных обстоятельствах (плохое программирование или дезинфекция) они not equalsмогут быть пропущены, тогда как less thanони все еще будут действовать.

Вот один пример, когда отсутствие проверки очистки привело к странным результатам: http://www.michaeleisen.org/blog/?p=358

Вот одна из причин, почему вы предпочитаете использовать, <а не !=. Если вы используете язык с глобальной областью видимости переменных, что произойдет, если другой код изменится i? Если вы используете <вместо !=, то худшее, что происходит, - это то, что итерация заканчивается быстрее: возможно, какой-то другой код увеличивается iслучайно, и вы пропускаете несколько итераций в цикле for. Но что произойдет, если вы выполняете цикл от 0 до 10, и цикл становится равным 9, и по какой- iто странной причине некоторые плохо записанные потоки увеличиваются . Затем ваш цикл завершает эту итерацию и увеличивает ее iдо значения 11. Теперь, когда цикл пропустил условие выхода ( iникогда не равное 10), он теперь будет выполняться бесконечно.

Это не обязательно должно быть особенно причудливой логикой типа threading-and-global-variable, которая вызывает это. Возможно, вы просто пишете цикл, который необходимо откатить назад. Если вы мутируете iв цикле и запутываете свою логику, то, имея ее так, чтобы она имела верхнюю границу, а не a, !=вы вряд ли оставите вас в бесконечном цикле.

Во встроенном мире, особенно в шумной среде, вы не можете рассчитывать на то, что ОЗУ будет вести себя должным образом. В условном (для, в то время как, если), где вы сравниваете, используя '==' или '! =', Вы всегда рискуете, что ваши переменные пропустили это критическое значение, которое завершает цикл - это может иметь катастрофические последствия - Mars Lander уровень последствий. Использование «<» или «>» в ​​условии обеспечивает дополнительный уровень безопасности для обнаружения «неизвестных неизвестных».

В исходном примере, если бы по iнеобъяснимым причинам катапультировалось до значения, намного превышающего 10, сравнение «<» сразу же уловит ошибку и выйдет из цикла, но «! =» Продолжит считать, пока не iобернется вокруг 0 ​​и обратно. до 10.