Следует ли использовать <или <= в цикле for

Question

Если бы вам пришлось повторять цикл 7 раз, вы бы использовали:

for (int i = 0; i < 7; i++)

или

for (int i = 0; i <= 6; i++)

Есть два соображения:

• производительности
• удобочитаемость

Для производительности я предполагаю Java или C #. Имеет ли значение, если используется «меньше» или «меньше или равно»? Если у вас есть понимание другого языка, укажите, какой.

Для удобства чтения я предполагаю массивы, основанные на 0.

UPD: Мое упоминание о массивах на основе 0 может привести к путанице. Я не говорю об итерации элементов массива. Просто общий цикл.

Ниже приведен хороший пункт об использовании константы, которая объясняет, что это за магическое число. Так что, если бы у меня было "int NUMBER_OF_THINGS = 7", то "i <= NUMBER_OF_THINGS - 1" выглядело бы странно, не правда ли.

Answer 1

Я всегда предпочитал:

for ( int count = 7 ; count > 0 ; -- count )

Answer 2

Не используйте магические числа.

Почему это 7? (или 6 в этом отношении).

используйте правильный символ для номера, который вы хотите использовать ...

В таком случае я думаю, что лучше использовать

for ( int i = 0; i < array.size(); i++ )

Answer 3

Есть много веских причин, чтобы написать мне <7. Хорошо иметь число 7 в цикле, которое повторяется 7 раз. Производительность практически идентична. Почти все пишут, что я <7. Если вы пишете для удобства чтения, используйте форму, которую все сразу узнают. </p>

Answer 4

Так много ответов ... но я верю, что мне есть что добавить.

Я предпочитаю, чтобы буквальные числа ясно показывали , какие значения "i" примет в цикле . Так что в случае итерации через массив, начинающийся с нуля:

for (int i = 0; i <= array.Length - 1; ++i)

И если вы просто зацикливаетесь, а не просматриваете массив, подсчет от 1 до 7 довольно интуитивен:

for (int i = 1; i <= 7; ++i)

Читаемость влияет на производительность до тех пор, пока вы не профилируете ее, поскольку вы, вероятно, не знаете, что компилятор или среда выполнения будут делать с вашим кодом до тех пор.

Answer 5

Отличный вопрос. Мой ответ: используйте тип A ('<') </p>

• Вы ясно видите, сколько у вас итераций (7).
• Разница между двумя конечными точками - это ширина диапазона
• Меньше символов делает его более читабельным
• У вас чаще всего общее количество элементов i < strlen(s), а не индекс последнего элемента , поэтому важна однородность.

Другая проблема связана со всей этой конструкцией. i появляется 3 раза , так что это может быть опечатано. Конструкция for-loop говорит , как делать вместо , что делать . Я предлагаю принять это:

BOOST_FOREACH(i, IntegerInterval(0,7))

Это более понятно, компилируется точно так же, как инструкции asm и т. Д. Спросите меня, если хотите, код IntegerInterval.

Answer 6

Как заметили люди, нет разницы ни в одной из двух упомянутых вами альтернатив. Просто чтобы подтвердить это, я сделал несколько простых тестов в JavaScript.

Вы можете увидеть результаты здесь . Из этого не ясно, что если я поменяю местами 1-й и 2-й тесты, результаты этих двух тестов поменяются местами, это явно проблема с памятью. Однако третий тест, в котором я меняю порядок итераций, явно быстрее.

Answer 7

Как все говорят, принято использовать 0-индексированные итераторы даже для вещей вне массивов. Если все начинается в 0 и заканчивается в n-1, а нижние границы всегда <=, а верхние границы всегда <, то при просмотре кода нужно гораздо меньше думать, чем нужно.

Answer 8

Операторы '<' и '<=' имеют одинаковую стоимость производительности. </p>

Оператор '<' является стандартным и его легче читать в цикле, начинающемся с нуля. </p>

Использование ++ i вместо i ++ повышает производительность в C ++, но не в C # - я не знаю о Java.

Answer 9

Сначала сделайте читабельность, потом оптимизируйте (хотя, честно говоря, я не представляю никакой разницы, которая была бы заметна).

Имейте в виду, что форма 0 -> K - это идиома C, перенесенная в C # благодаря наличию массивов на основе 0. Следуй идиоме и не нарушай принципа наименьшего удивления.

Answer 10

Я бы сказал, что это должно быть <. </p>

Зачем использовать много слов, если мало? Один тест легче понять, чем два. Следовательно, проще выполнить модульное тестирование и изменить его в дальнейшем.

Разница маленькая? Да. Но зачем добавлять какую-либо сложность, когда это не оправдано.

Наконец, вы не зависите от какого-либо оптимизатора или реализации интерпретатора, когда код оптимизирован для начала. По словам Эйнштейна, «делайте это как можно проще, но не проще».