Почему while только тогда, когда нет нужды во втором итеративном свойстве?

Question

[vasIvas]

Вот почему я не первый раз слышу упреки при использовании while тогда, когда есть нужда во втором, итеративном свойстве? Типа -

var lenght = array.lenght,
count      = 0;

while(count < lenght){}

Почему это неправильно, если мне так больше нравится?

Comments

[Родион Мещеряков]

Почему бы не спросить об этом у тех, кто делает замечания?

Answer 1

[Евгений Петров]

Нет абсолютно никакой разницы между for и while, кроме инструкции continue.

Answer 2

[Константин Китманов]

Вы любите спотыкаться?

Современные программные продукты настолько сложны, что написать их в одиночку практически нереально — за время написания релизятся конкуренты и труд нескольких месяцев, если не лет, летит в трубу.
Поэтому кодят в команде.
А в команде, как в любом коллективе, твоя свобода кончается там, где начинается свобода соседа. Поэтому надо сосуществовать и вырабатывать общие правила поведения. Например, стайлгайды для кода и паттерны проектирования.

Конечно, ничего особо плохого в том, чтобы обходить массив по while, нету. Но так не делают (хотя бы потому, что в for(;;) не надо вручную менять счетчик). А раз так не делают, ваши коллеги каждый раз взглядом спотыкаются об этот кусок.

Answer 3

[bromzh]

Просто цикл for выглядит более ясно и понятно, если надо перебрать некую коллекцию. В случае while можно напортачить с изменением счётчика. While обычно используют, если критерий выхода из цикла - некое логическое значение. А for - если идёт итерация по коллекции (массив или объект).

Comments

[Евгений Петров]

Напортачить можно везде. Про логическое значение и итерацию по коллекции — это шутка?

[bromzh]

@Petroveg Нет не шутка. Что смешного я написал?

[Евгений Петров]

Где тут логическое значение?

while (e.firstChild) {
	e.removeChild(e.firstChild);
}

А тут где?

for (var i = 0; e[i]; i++) {
	...
}

А вот первый пример, только с for

for (; e.firstChild;) {
	e.removeChild(e.firstChild);
}

[_ _]

@Petroveg предположу, что имелось в виду for(item in collection){}
Также одна из проблем итерерования с использованием счетчика - проблема граничных значений

[Евгений Петров]

@AMar4enko если бы речь шла про массив, то лучше forEach, search, reduce, every и прочие прелести:)
Я просто к тому, что и for, и while может использоваться без явного счётчика. И предложенные критерии вовсе не то.

[vasIvas]

Не, я о for(i; i < length; i++){}... И в первом Вашем примере while (e.firstChild), это ведь не правильно и работает лишь из-за того, что разработчики позаботились о приведении типов. для меня такая запись выглядит, как слон, которого в банку хотят засунуть. Я бы так написал while (e.firstChild != null)..
Мне просто говорили, что такая запись НЕ ЧИТАБЕЛЬНА ( бил бы за эту фразу )...
А мне так лучше и вот сидел я, сидел, писал и решил спросить...

[Евгений Петров]

@vasIvas неправильно?)) Вы просто тогда не тот язык учите.

[vasIvas]

@Petroveg , идеологически, нет! Если условие ожидается логическое, а ему undefined или null суют, то что? Приведение типов. А для меня это, как из ежа тащить дикобраза. И такое во многих языках работает, но не означает, что ПРАВИЛЬНО.

[Евгений Петров]

@vasIvas это — исключительно правильно, если нет определения типа переменной при её объявлении.

[vasIvas]

@Petroveg , можно у Вас поинтересоваться, undefined и null в js были всегда с самой первой версии?

[Евгений Петров]

@vasIvas я первой версии в глаза не видел:) То ли 3-я, то ли 4-я версия EcmaScript была. Думаю, было и то, и то.
Ваша проверка != null не имеет смысла. Только !== null.

[vasIvas]

Получается, если сделали и null и undefined, значит одного false мало ведь, а если мало, то почему же проверка на null НЕПРАВИЛЬНО?

И по поводу проверок.. Вы мне кажется ошибаетесь... Моя НЕ строгая проверка подтверждает, что undefined НЕ РАВЕН null, а Ваша строгая утверждает, две вещи, первая из которых - undefined ДЕЙСТВИТЕЛЬНО не равно null.

[Евгений Петров]

@vasIvas

console.log(undefined != null); // false
console.log(undefined !== null); // true

[vasIvas]

@Petroveg , и? В Вашем случаи firstChild это свойство объекта e. Если свойства нет, то возвращено будет undefined. И получается, что свойства нет, а console.log(undefined !== null); // true...
Хотя, там на том конце должно быть null... Ведь если там должен быть объект-инстенс, а не примитив, то правильнее было бы иметь нуль по дефолту или при занулении ссылки. Тогда сорри! Я не прав, Вы правы.

[bromzh]

@Petroveg Я имел ввиду немного другое.
Если использовать while как аналог for (т.е. берём длину массива, устанавливаем счётчик, в теле while его инкрементируем и сравниваем с длиной массива), то это чушь. For подходит намного лучше для таких целей. Потому что вместо 4-х строчек всё записывается в одну. Поэтому для прохода по массиву или объекту лучше брать for. Конечно, можно всё переписать и на while, но зачем?
While же удобно применять в несколько других случаях.
1) Проверка на некое логическое условие, которое не требует счётчика. Банальный пример: надо заполнить множество 100 случайными числами, значения которых будут от 1 до 200. Да, можно и в for это замутить, но нагляднее будет сделать это while'ом: while(set.length < 100) { set.add(random(200)) }. (это псевдокод, естественно). Ещё пример - получать данные, пока не будет получено сообщение о выходе или о конце файла/потока данных/etc: while(msg != 'exit') { msg = readData(source) }. Опять же, можно и for'ом сделать, но это while в данном случае, более наглядный и понятный.
2) Итераторы в Java стиле: while(iterator.hasNext()) { data = iterator.getValue(); doSomething(data) }.

[Евгений Петров]

@bromzh да я понимаю, чём вы. Просто логическое значение — вовсе не та грань, что отделяет for от while. Я и пример привёл вполне себе жизненный — удаление из узла всех детей, но в нём в условии всегда будет объект (ссылка или null). И что это, если не итерация по коллекции.
А for можно написать со сравнением и получать логическое значение в условии.

[Александр Кит]

@bromzh, в ес5 я был сторонником такой итерации:

var imax = array.length,
      i = -1;
while(++i < imax) {}

Здесь мы явно разделяем декларацию переменных и сам цикл - например, мы легко можем сделать дополнительные проверки или что ещё нужно перед началом цикла.
Вместо одной длинной строчки имеем 3 коротких - для чтения более приятно, но это субъективно.

[bromzh]

@Petroveg Да, с логической переменной я переборщил) Просто сложно выразить, когда конкретно нужен while, тут уж дело привычки и некая интуиция, выработанная годами кодинга.
Во многих языках в for можно вставлять сложные условия изменения переменной и/или условия завершения. В си-подобных циклах можно даже вычислять числа фиббоначчи и находить НОД, просчитывая значения только в определении цикла, а не в его теле. Но для просмотра всего массива намного нагляднее и понятнее использовать for, нежели while. Последний же, на мой взгляд, применяют реже.
Да и вообще, можно отказаться от циклов в пользу рекурсии (простой либо "итерационной").

[Евгений Петров]

@bromzh для массивов я уже писал выше — ввели массу циклов на все случаи жизни. А для объектов неприкасаемый for in (да ниспошлёт молнии Зевс на голову говнокодеров, гадящих в прототип Object).

Я не пытаюсь опорочить ваш подход, просто критерии не те. Можно было бы сказать, что для while лучше, если объект проверки автоматически изменяется в теле цикла. И я бы только заплюсовал такой ответ:)

Но логическое значение... Да ещё и про Javascript, где без === не отличишь, кто чёрт, а кто просто погулять вышел...

Answer 4

[Александр Кит]

Уже давно пора использовать es6, итерация по массиву с for..of намного приятнее.

А пока, while и for отличаются между собой как слова "цикл" и "итерация". Немного лирики)
- "Через цикл можно осуществить итерацию, но через итерацию нельзя выразить цикл."
- или, "Не любой цикл является итерацией, но любая итерация является циклом"
Пример: когда for становится эквивалентным while - это for(;condition;){}, но так писать не имеет смысла, такой statement должен сколапсировать в while(condition){}.
Из этого следует, что while более универсальный, тем самым менее выразительный. Тогда как for нацелен лишь на итерацию, тем самым более выразительный.

Так и что использовать? Как по мне, так это то, что вам нравится. Меня всегда настораживает, когда кто-то упрекает стилистику кода, ну а здесь и вовсе не может быть дискуссий, ведь оба варианта одинаково-хорошо лаконичны, и в производительности различиями можно пренебречь.

А вот за for(var i in array){} и вправду можно обосновано поупрекать.