Я всегда следую правилу что, если это должно выполнить нуль или больше раз, тест вначале, если это должно работать однажды или больше, тест в конце. Я не вижу логических оснований для использования кода, который Вы перечислили в своем примере. Это только добавляет сложность.

В типичном Дискретном классе Структур в информатике это - легкое доказательство, что существует эквивалентность, отображающаяся между двумя.

Стилистически, я предпочитаю, в то время как (легкий-expr) {}, когда легкий-expr известен честный и готовый пойти, и цикл не имеет большого количества повторных издержек/инициализации. Я предпочитаю, делают {} в то время как (somewhat-less-easy-expr); когда там более повторяется наверху, и условие не может быть вполне так просто настроить загодя. Если я пишу бесконечный цикл, я всегда использую в то время как (верный) {}. Я не могу объяснить, почему, но мне просто не нравится писать для (;;) {}.

Необходимо сначала думать о тесте как о части кода цикла. Если тест логически принадлежит в начале обработки цикла, то это - тест top-of-the-loop. Если тест логически принадлежит в конце цикла (т.е. это решает, должен ли цикл продолжить работать), то это - вероятно, тест bottom-of-the-loop.

необходимо будет сделать что-то воображение, если тест логически принадлежит их середина.:-)

Это действительно зависит существуют ситуации, когда Вы хотите протестировать наверху, другие, когда Вы хотите протестировать в нижней части, и все еще других, когда Вы хотите протестировать в середине.

Однако данный пример кажется абсурдным. Если Вы собираетесь протестировать наверху, не используйте, если оператор и тест в нижней части, просто используйте некоторое время оператор, вот что это значит сделанный для.

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

Оба соглашения корректны, если Вы знаете, как записать код правильно:)

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

a++;
while (a < n) {
  a++;
}

может быть записан более кратко с помощью

do {
  a++;
} while (a < n)

, Конечно, этот конкретный пример может быть записан еще более кратким способом как (принятие синтаксиса C)

while (++a < n) {}

, Но я думаю, что Вы видите точку здесь.

Это на самом деле предназначено для разные вещи. В C можно использовать , делают - в то время как конструкция для достижения и сценария (работает, по крайней мере, однажды и выполнения в то время как верный). Но ПАСКАЛЬ имеет повторение - до и , в то время как для каждого сценария, и если я помню правильно, ADA имеет другую конструкцию, которая позволяет Вам выйти в середине, но конечно это не то, что Вы спрашиваете. Мой ответ на Ваш вопрос: Мне нравится мой цикл с тестированием на вершине.

Для любого, кто не может думать о причине иметь цикл одного или нескольких раз:

try {
    someOperation();
} catch (Exception e) {
    do {
        if (e instanceof ExceptionIHandleInAWierdWay) {
            HandleWierdException((ExceptionIHandleInAWierdWay)e);
        }
    } while ((e = e.getInnerException())!= null);
}

то же могло использоваться для любого вида иерархической структуры.

в классе Узел:

public Node findSelfOrParentWithText(string text) {
    Node node = this;
    do {
        if(node.containsText(text)) {
            break;
        }
    } while((node = node.getParent()) != null);
    return node;
}

Вот перевод:

do { y; } while(x); 

То же как

{ y; } while(x) { y; }

Примечание дополнительный набор фигурных скобок для случая, у Вас есть определения переменной в y. Объем тех должен быть сохранен локальным как в случае-цикла. Так, цикл с условием продолжения просто выполняет свое тело, по крайней мере, однажды. Кроме этого, эти два цикла идентичны. Таким образом, если мы применяем это правило к Вашему коду

do {
    // do something
} while (condition is true);

, соответствующий цикл с условием продолжения для Вашего-цикла похож

{
    // do something
}
while (condition is true) {
    // do something
}

Да, Вы видите соответствие, в то время как для Вашего действительно циклично выполняются, отличается от Вашего в то время как:)

Различие - то, что действительно циклично выполняются, выполняется, "делают что-то" однажды, и затем проверяет условие видеть, должно ли оно повториться, "делают что-то", в то время как цикл с условием продолжения проверяет условие прежде, чем сделать что-либо

Сначала нельзя выполниться вообще, если условие является ложью. Другой выполнится, по крайней мере, однажды, затем проверить conidition.

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

Первые тесты условие прежде, чем работать так это возможно Ваш код, никогда не будут вводить код внизу. Второе выполнит код в прежде, чем протестировать условие.

Варианты использования отличаются для двух. Это не вопрос "о лучших практиках".

, Если Вы хотите, чтобы цикл выполнился на основе условия исключительно, чем использование для или , в то время как

, Если Вы хотите сделать что-то однажды независимо от, условие и затем продолжать делать его основывало оценку условия. делают.. в то время как

, в то время как () проверки условие перед каждым выполнением тела цикла и делают... в то время как () проверки условие после каждого выполнения тела цикла.

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

Функционально, некоторое время () эквивалентно

startOfLoop:
    if (!condition)
        goto endOfLoop;

    //loop body goes here

    goto startOfLoop;
endOfLoop:

и..., в то время как () эквивалентно

startOfLoop:

    //loop body

    //goes here
    if (condition)
        goto startOfLoop;

Примечание, что реализация, вероятно, более эффективна, чем это. Однако..., в то время как () действительно включает тот меньше сравнения, чем некоторое время (), таким образом, это немного быстрее. Используйте... в то время как () если:

• Вы знаете , что условие всегда будет верно в первый раз вокруг, или
• Вы хотите цикл выполниться однажды, даже если условие является ложью для начала.

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

Я бы сказал, что писать циклы if..do.. while - плохая практика по той простой причине, что это увеличивает размер код и вызывает дублирование кода. Дублирование кода подвержено ошибкам, и его следует избегать, так как любое изменение одной части должно выполняться и на дубликате, что не всегда так. Кроме того, чем больше размер кода, тем сложнее будет работать с кешем процессора. Наконец, он обрабатывает нулевые случаи и решает головные боли.

Только когда первый цикл принципиально отличается, следует использовать do .. в то время как, скажем, если код, который заставляет вас передать условие цикла (например, инициализация), выполняется в петля. В противном случае,

На самом деле это не ответ, а повторение того, что сказал один из моих лекторов, и это меня тогда заинтересовало.

Два типа цикла while..do и do. На самом деле. while являются экземплярами третьего более общего цикла, в котором тест находится где-то посередине.

begin loop
  <Code block A>
  loop condition
  <Code block B>
end loop

Кодовый блок A выполняется по крайней мере один раз, а B выполняется ноль или более раз, но не выполняется на самой последней (неудачной) итерации. цикл while - это когда кодовый блок a пуст, а do.. while - когда кодовый блок b пуст. Но если вы пишете компилятор, вам может быть интересно обобщить оба случая на такой цикл.

Чтобы написать правильный код, в основном нужно провести мысленное, возможно, неформальное доказательство правильности.

Чтобы доказать правильность цикла, стандартный способ - выбрать инвариант цикла, и индукционное доказательство. Но пропустите сложные слова: то, что вы делаете неформально, - это выясняете что-то, что является истинным для каждой итерации цикла, и что, когда цикл завершен, то, что вы хотели выполнить, теперь истинно. Инвариант цикла ложен в конце, чтобы цикл завершился.

Если условия цикла довольно легко отображаются в инвариант, и инвариант находится наверху цикла, и можно сделать вывод, что инвариант истинен в при следующей итерации цикла, работая с кодом цикла, легко определить, что цикл правильный.

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

Я думаю, некоторые люди проводят тестирование внизу, потому что вы можете сэкономить один или несколько машинных циклов, выполнив это 30 лет назад.

Исходя из моих ограниченных знаний о генерации кода, я думаю, что может быть хорошей идеей написать нижние тестовые циклы, поскольку они позволяют компилятору лучше выполнять оптимизацию циклов. Для нижних тестовых циклов гарантируется, что цикл выполняется хотя бы один раз. Это означает, что инвариантный код цикла «доминирует» над выходным узлом. Таким образом, его можно безопасно перемещать непосредственно перед началом цикла.

Используйте циклы while, если вы хотите проверить условие перед первой итерацией цикла.

Используйте циклы do-while, если вы хотите проверить условие после выполнения первой итерации цикла.

Например, если вы обнаружите, что делаете что-то вроде любого из этих фрагментов:

func();
while (condition) {
   func();
}

//or:

while (true){
    func();
    if (!condition) break;
}

, вам следует переписать его как:

do{
    func();
} while(condition);

Как заметил Пиемасонс, разница заключается в том, выполняется ли цикл один раз перед выполнением теста или тест выполняется первым, так что тело цикла может никогда не выполняться.

Ключевой вопрос - что имеет смысл для вашего приложения.

Возьмем два простых примера:

1. Допустим, вы просматриваете элементы массива. Если в массиве нет элементов, вы не хотите обрабатывать номер один, равный нулю. Поэтому вам следует использовать WHILE.

2. Вы хотите отобразить сообщение, принять ответ, а если ответ недействителен, спрашивать еще раз, пока не получите действительный ответ. Так что всегда хочется спросить один раз. Вы не можете проверить, действителен ли ответ, пока не получите ответ, поэтому вам нужно пройти через тело цикла один раз, прежде чем вы сможете проверить условие. Вы должны использовать DO / WHILE.

Да... это правда... do while будет выполняться по крайней мере один раз. Это единственное различие. Больше не о чем спорить

Вот хороший пример из реальной жизни, с которым я недавно столкнулся. Предположим, у вас есть несколько задач обработки (например, обработка элементов в массиве), и вы хотите разделить работу между одним потоком на каждое имеющееся ядро ​​ЦП. Для выполнения текущего кода должно быть хотя бы одно ядро! Так что вы можете использовать do ...while что-то вроде:

do {
    get_tasks_for_core();
    launch_thread();
} while (cores_remaining());

Это почти ничтожно, но, возможно, стоит учесть выигрыш в производительности: его можно также записать как стандартный цикл while , но это всегда будет делать ненужное начальное сравнение который всегда будет оценивать истинно - а на одноядерном процессоре ветвление условия do-while выполняется более предсказуемо (всегда ложно, по сравнению с чередованием истинного / ложного для стандартного , а ).

Помогает ли отказ от сделать / , а действительно сделать мой код более читабельным?

Нет.

Если имеет смысл использовать цикл do / while , сделайте это. Если вам нужно выполнить тело цикла один раз перед проверкой условия, то цикл do / while , вероятно, является наиболее простой реализацией.

Я сам предпочитаю циклы do-while. Если условие всегда будет истинным в начале цикла, я предпочитаю проверить его в конце. На мой взгляд, весь смысл условий тестирования (кроме утверждений) в том, что результат теста неизвестен. Если я вижу цикл while с проверкой условия вверху, я склоняюсь к рассмотрению случая, когда цикл выполняется ноль раз. Если этого никогда не произойдет, почему бы не написать код, который ясно показывает это?

Да, точно так же, как использование for вместо while или foreach вместо for улучшает читаемость. Тем не менее, некоторые обстоятельства требуют выполнения while, и я согласен, что было бы глупо помещать эти ситуации в цикл while.

Полезнее думать в терминах обычного употребления. Подавляющее большинство циклов while вполне естественно работают с , а , даже если их можно заставить работать с do ... while , так что в основном вы должны использовать его, когда разница отсутствует. t имеет значение. Поэтому я бы использовал do ... в то время как в редких случаях, когда он обеспечивает заметное улучшение читабельности.

Как правило, это зависит от того, как вы структурируете свой код. И, как кто-то уже ответил, для некоторых алгоритмов требуется хотя бы одна итерация. Итак, чтобы избежать дополнительного количества итераций или флага хотя бы одного взаимодействия, вы используете do / while.