Я слышал, что некоторые перерывы - неплохая практика. Что насчет этого?

В этом случае мне кажется, что было бы проще просто изменить условие while:

while (numPrime < 10001) {

Обычно это происходит, когда цикл while(true) заканчивается на

if (condition)
{
    break;
}

... хотя вам нужно проверить, выполняет ли что-нибудь еще в теле цикла continue.

В качестве альтернативы вы можете немного реструктурировать его:

int current = 1;
for (int i = 0; i < 10001; i++)
{
    current++;
    while (!isPrime(current))
    {
        current++;
    }
}

Тогда current будет ответом в конце.

Я обычно предпочитаю цикл for циклу while, когда вы пытаетесь сделать что-то определенное количество раз. В этом случае «что-то» - это «найти следующее простое число».

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

Я не уверен, что перерывы вообще плохая практика, но думаю, что это так.

Это немного глупо, потому что в этом нет необходимости. Ваш while (true) ... break полностью эквивалентен:

while (numPrime < 10001) {
   ...
}

но гораздо менее интуитивно понятный.

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

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

Было бы сложно (и я буду спорить, бесполезно) пытаться придумать жесткие правила о том, когда использовать break, а когда извлекать переменные и использовать вместо них условные выражения. Часто легко сказать, какой вариант самый простой, но не всегда. Это один из тех примеров, когда действительно имеет значение опыт - чем больше хорошего / плохого кода вы прочитали и написали сами, тем больше ваша личная библиотека хороших и плохих примеров и тем легче вам будет сказать, какой из них «лучший». "* способ представить данную концепцию.

* Конечно субъективно!

если вы можете уйти без перерыва, то сделайте это.

do

 while (numPrime < 10001) ...

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

while (true) {
    first part;
    if (finished) 
       break;
    second part;
}

можно превратить во что-то вроде:

first part;
while (!finished) {
    second part;
    first part;
}

or:

while (!finished) {
    first part;
    if (!finished)
        second part;
}

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

Вот для чего был изобретен do / while:

do {
//...
} while(numPrime < 10001);

Это while(true) бит, который я считаю плохой практикой, что, конечно же, приводит к break.

Не сильно отличается от всего, что было сказано ранее, но с точки зрения удобочитаемости и прозрачной логики я бы порекомендовал

long i,primes=0;
for (i=2;primes<10001;i++) {
    if (isPrime(i))
        primes++;
}

я - ответ.

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

Я действительно думаю, что "do {} while (1);" определенно можно использовать; петля. Из их:

1. In the loop-continue case, the primary condition needs to have enough code run both before and after it is checked that putting the code in the condition itself would be awkward at best.
2. The loop has multiple exit conditions, and the exit condition which would most logically sit at the top or bottom of the loop would require special code to execute which should not execute for other exit conditions.

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

Если вас не слишком заботит скорость, можно никогда не использовать любую форму goto, преждевременного выхода return или, если на то пошло, использовать более одного while - и это с простым условием. Просто напишите всю программу как конечный автомат:

void do_whatever(void)
{
  int current_state=1;
  do
  {
    next_state = 0;
    if (current_state == 1)
    {
      do_some_stuff();
      next_state = 2;
    }
    if (current_state == 2)
    {
      do_some_more_stuff();
      next_state = 3;
    }
    ...
    current_state = next_state;
  } while(current_state);
}

Иногда такое кодирование полезно (особенно если «while» можно вывести из подпрограммы do_whatever () в цикл, который запускает несколько подпрограмм с аналогичным кодом «одновременно»). И никогда не нужно использовать что-то вроде «goto». Но для удобочитаемости конструкции структурного программирования намного приятнее.

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

  if (index >= numItems)
  {
    createNewItem(index);
    break;
  }

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

Как отмечали другие, приведенный вами пример плох, потому что вы можете легко перенести тест в WHILE.

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

while (true)
{
  String inLine=inStream.readLine();
  if (inLine.startsWith("End"))
    break;
  ... process line ...
}

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

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

while (!endOfInterestingData(inStream))
{
  ... process ...
}

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

Это решение довольно быстрое:

#include <stdio.h>

unsigned long isqrt(unsigned long n) {
    // http://snippets.dzone.com/posts/show/2715
    unsigned long a;
    for (a = 0; n >= (2*a)+1; n -= (2*a++) + 1);
    return a;
}

void nPrimes(const long N, long *const primes)
{
    unsigned long n, count, i, root;

    primes[0] = 2;
    count = 1;

    for (n = 3; count < N; n+=2) {

        root = isqrt(n);

        for (i = 0; primes[i] <= root; i++) {
            if ((n % primes[i]) == 0) goto notPrime;
        }
/*      printf("Prime #%lu is: %lu\n", count+1, n);*/
        primes[count++] = n;

        notPrime: ;
    }
}

int main (int argc, char **argv)
{
    long N;

    if (argc > 1) {
        N = atoi(argv[1]);
    } else {
        N = 10001;
    }

    long primes[N];

    nPrimes(N, primes);

    printf("Prime #%lu is: %lu\n", N, primes[N-1]);
}

Примечания:

• isqrt (n) - пол (sqrt (n)). Это позволяет избежать операций с плавающей запятой, которые нам в любом случае не нужны. Алгоритм из http://snippets.dzone.com/posts/show/2715.
• nPrimes хранит список простых чисел. Это позволяет вам тестировать только простые делители, что исключает большинство дорогостоящих операций с модификациями.
• Даже простые числа проверяются только до isqrt (n).
• Это уродливый goto, но C не имеет имени continue, и переменная флага была бы пустой тратой времени.
• Массив простых чисел инициализируется значением 2, и он проверяет только нечетные числа из 3. Удаление числа, кратного 3, аналогично выполнимо, но не тривиальной сложности.
• Вызов isqrt можно исключить, если вести таблицу квадратов простых чисел. Это почти наверняка перебор, но вы можете, если хотите.
• На моей не новой машине это происходит в мгновение ока.