Так ли плохи циклы while(true)?

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

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

В качестве примера того, где лучше использовать break, чем флаг, рассмотрим:

while (true)
{
    doStuffNeededAtStartOfLoop();
    int input = getSomeInput();
    if (testCondition(input))
    {
        break;
    }
    actOnInput(input);
}

Теперь давайте заставим его использовать флаг:

boolean running = true;
while (running)
{
    doStuffNeededAtStartOfLoop();
    int input = getSomeInput();
    if (testCondition(input))
    {
        running = false;
    }
    else
    {
        actOnInput(input);
    }
}

Я считаю последний более сложным для чтения: у него есть дополнительный блок else, actOnInput имеет больший отступ, и если вы пытаетесь понять, что происходит, когда testCondition возвращает true, вам нужно внимательно просмотреть остальную часть блока. чтобы убедиться, что нет ничего после блока else, которое могло бы произойти независимо от того, установлено ли running значение false или нет.

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

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

AFAIK ничего, на самом деле. У учителей просто аллергия на goto, потому что где-то слышали, что это очень плохо. В противном случае вы бы просто написали:

bool guard = true;
do
{
   getInput();
   if (something)
     guard = false;
} while (guard)

Что почти одно и то же.

Может быть, это чище (потому что вся информация о цикле содержится в верхней части блока):

for (bool endLoop = false; !endLoop;)
{

}

У Дугласа Крокфорда было замечание о том, что он хотел бы, чтобы JavaScript содержал структуру loop:

loop
{
  ...code...
}

И я не думаю, что Java будет хуже, если будет иметь структуру loop.

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

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

while( a() )
{
  fn();
}

такой же как

loop
{
  if ( !a() ) break;
  fn();
}

и

do
{
  fn();
} while( a() );

такой же как:

loop
{
  fn();
  if ( !a() ) break;
}

и

for ( a(); b(); c() )
{
  fn();
}

такой же как:

a();
loop
{
  if ( !b() ) break;
  fn();
  c();
}

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

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

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

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

Очевидно, что это не единственная парадигма программирования, но часто ее можно легко применить к другим парадигмам, таким как объектно-ориентированное программирование (например, Java).

Ваши учителя, вероятно, учили и пытаются научить ваш класс тому, что нам лучше избегать «кода спагетти», убедившись, что наш код структурирован и следует подразумеваемым правилам структурного программирования.

Хотя в реализации, использующей break, нет ничего изначально «неправильного», некоторые считают, что значительно легче читать код, в котором условие для цикла явно указано в условии while(), и устраняются некоторые возможности чрезмерной хитрости. Определенно существуют ловушки при использовании условия while(true), которые, кажется, часто появляются в коде у начинающих программистов, например, риск случайного создания бесконечного цикла или создания кода, который трудно читать или излишне запутывать.

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

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

Обычное соглашение Java для чтения ввода:

import java.io.*;
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
String strLine;

while ((strLine = br.readLine()) != null) {
  // do something with the line
}

И обычное соглашение С++ для чтения ввода:

#include <iostream>
#include <string>
std::string data;
while(std::readline(std::cin, data)) {
  // do something with the line
}

А в C это

#include <stdio.h>
char* buffer = NULL;
size_t buffer_size;
size_t size_read;
while( (size_read = getline(&buffer, &buffer_size, stdin)) != -1 ){
  // do something with the line
}
free(buffer);

или если вы уверены, что знаете длину самой длинной строки текста в вашем файле, вы можете сделать

#include <stdio.h>
char buffer[BUF_SIZE];
while (fgets(buffer, BUF_SIZE, stdin)) {
  //do something with the line
}

Если вы проверяете, ввел ли ваш пользователь команду quit, легко расширить любую из этих трех структур цикла. Я сделаю это на Java для вас:

import java.io.*;
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
String line;

while ((line = br.readLine()) != null  && !line.equals("quit") ) {
  // do something with the line
}

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

Это не такая уж страшная вещь, но при кодировании нужно учитывать других разработчиков. Даже в школе.

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

При этом вы все еще будете видеть подобные вещи в МНОЖЕСТВЕ кода в реальном мире.

Это твой пистолет, твоя пуля и твоя нога...

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

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

Почему? Мне нужно было выяснить, почему приложение 700K LOC постепенно начинает сжигать 100% процессорного времени, пока каждый процессор не будет загружен. Это был удивительный цикл while (настоящий). Он был большим и неприятным, но сводился к следующему:

x = read_value_from_database()
while (true) 
 if (x == 1)
  ...
  break;
 else if (x ==2)
  ...
  break;
and lots more else if conditions
}

Не было конечной else ветки. Если значение не соответствовало условию if, цикл продолжал работать до конца времени.

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

ИМХО, использование таких конструкций, как while(true), не является хорошим защитным программированием. Он вернется, чтобы преследовать вас.

(Но я помню, как профессора снижали оценки, если мы не комментировали каждую строку, даже для i++;)

Это плохо в том смысле, что структурированные конструкции программирования предпочтительнее (несколько неструктурированных) операторов break и continue. Для сравнения, по этому принципу они предпочтительнее «goto».

Я всегда рекомендую делать ваш код как можно более структурированным... хотя, как указывает Джон Скит, не делайте его более структурированным!

По моему опыту, в большинстве случаев циклы имеют «основное» условие для продолжения. Это условие должно быть записано в сам оператор while(). Все остальные условия, которые могут нарушить цикл, являются второстепенными, не столь важными и т. д. Их можно записать в виде дополнительных операторов if() {break}.

while(true) часто сбивает с толку и менее читаем.

Я думаю, что эти правила охватывают не 100% случаев, а, наверное, только 98%.

Хотя это и не обязательно ответ на вопрос, почему бы не использовать while (true), я всегда находил этот комикс и сопровождающее заявление автора краткое объяснение того, почему нужно делать while вместо do-while.

Что касается вашего вопроса: нет внутренней проблемы с

while(true) {
   do_stuff();
   if(exit_time) {
      break;
   }
}

... если вы знаете, что делаете, и следите за тем, чтобы exit_time в какой-то момент оценивалось как true.

Учителя не рекомендуют вам использовать while(true), потому что до тех пор, пока вы не осознаете, что делаете, это простой способ совершить критическую ошибку.

Вы можете просто использовать логический флаг, чтобы указать, когда закончить цикл while. Break и go to были причинами того, что программное обеспечение трудно поддерживать - программный кризис (tm) - и его следует избегать, и его легко можно избежать.

Вопрос в том, прагматичен ты или нет. Прагматичные программисты могут просто использовать break в этой простой ситуации.

Но полезно выработать привычку не использовать их, иначе вы можете использовать их по привычке в неподходящих ситуациях, например, в сложных вложенных циклах, где читабельность и ремонтопригодность вашего кода становится сложнее из-за использования break.

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

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

В вашем примере кажется намного понятнее сделать что-то вроде:

do {
   input = get_input();
   valid = check_input_validity(input);    
} while(! valid)

Это особенно верно, если цикл do while становится длинным — вы точно знаете, где выполняется проверка, чтобы увидеть, не происходит ли дополнительная итерация. Все переменные/функции имеют соответствующие имена на уровне абстракции. Оператор while(true) говорит вам, что обработка не там, где вы думали.

Возможно, вам нужен другой вывод во второй раз в цикле. Что-то типа

input = get_input();
while(input_is_not_valid(input)) {
    disp_msg_invalid_input();
    input = get_input();
}

тогда мне кажется более читаемым

do {
    input = get_input();
    if (input_is_valid(input)) {
        break;
    }
    disp_msg_invalid_input();
} while(true);

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

Может быть, мне не повезло. А может мне просто не хватает опыта. Но каждый раз, когда я вспоминаю, что имел дело с while(true), имеющим break внутри, можно было улучшить код, применяя метод извлечения в while-block, который сохранил while(true), но (по совпадению?) преобразовал все break в return.

По моему опыту while(true) без перерывов (т.е. с возвратами или бросками) вполне удобны и понятны.

  void handleInput() {
      while (true) {
          final Input input = getSomeInput();
          if (input == null) {
              throw new BadInputException("can't handle null input");
          }
          if (input.isPoisonPill()) {
              return;
          }
          doSomething(input);
      }
  }

Я использую что-то подобное, но с противоположной логикой, во многих своих функциях.

DWORD dwError = ERROR_SUCCESS;

do
{
    if ( (dwError = SomeFunction()) != ERROR_SUCCESS )
    {
         /* handle error */
         continue;
    }

    if ( (dwError = SomeOtherFunction()) != ERROR_SUCCESS )
    {
         /* handle error */
         continue;
    }
}
while ( 0 );

if ( dwError != ERROR_SUCCESS )
{
    /* resource cleanup */
}

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

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

Для меня проблема в читабельности.

Оператор while с истинным условием ничего не говорит вам о цикле. Это значительно усложняет работу по его пониманию.

Что было бы легче понять из этих двух фрагментов?

do {
  // Imagine a nice chunk of code here
} while(true);

do {
  // Imagine a nice chunk of code here
} while(price < priceAllowedForDiscount);

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

1) Нет ничего плохого в do -while(true)

2) Ваш учитель не прав.

НСФС!!:

3) Большинство учителей - учителя, а не программисты.

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