В то время как (верный) с повреждением плохая практика программирования?

использование циклов как

, в то время как (1) {действительно наполняют}

, необходимо в некоторых ситуациях. Если Вы сделаете какое-либо программирование встроенных систем (думайте микроконтроллеры как PIC, MSP430 и программирование DSP), то тогда почти весь Ваш код будет в некоторое время (1) цикл. При кодировании для DSPS иногда Вам просто нужно некоторое время (1) {}, и остальная часть кода является процедурой обработки прерывания (ISR).

То, что Вашего друга рекомендуют, отличается от того, что Вы сделали. Ваш собственный код более сродни

do{
    // do something
}while(!<some condition>);

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

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

while(true){
    // do something
if(<some condition>) break;
    // continue do something
}

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

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

His reasoning was that you could "forget the break" too easily and have an endless loop.

В некоторое время цикле Вы на самом деле просите процесс, который работает неограниченно долго, если чего-то не происходит, и если это, чего-то не происходит в определенном параметре, Вы получите точно, что Вы хотели... бесконечный цикл.

Я предпочитаю, в то время как(!) подход, потому что он более ясно и сразу передает намерение цикла.

Несколько преимуществ использования последней конструкции, которые прибывают по моему мнению:

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

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

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

Он, вероятно, корректен.

Функционально эти два могут быть идентичными.

Однако для удобочитаемость и понимание процесса выполнения программы, в то время как (условие) лучше. Повреждение порет больше goto своего рода. В то время как (условие) очень ясно на условиях, которые продолжают цикл и т.д. Это не означает, что повреждение является неправильным, просто может быть менее читаемым.

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

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

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

Существует существенно идентичный вопрос уже в ТАК в , ТО, В ТО ВРЕМЯ КАК TRUE†¦ BREAK†¦ ЗАКАНЧИВАЮТСЯ В ТО ВРЕМЯ КАК хороший дизайн? . @Glomek отвечают (в недооцененном сообщении):

Иногда это - очень хороший дизайн. См. Структурированное Программирование С Операторами перехода Donald Knuth для некоторых примеров. Я часто использую эту основную идею для циклов, которые выполняют "n с половиной времена", особенно читайте/обрабатывайте циклы. Однако я обычно пытаюсь иметь только один оператор завершения. Это облегчает рассуждать о состоянии программы после того, как цикл завершится.

Несколько позже, я ответил связанным, и также горестно недооценил, комментарий (частично, потому что я не заметил Glomek в первый раз вокруг, я думаю):

Одна захватывающая статья является "Структурным программированием Knuth с движением к Операторам" с 1974 (доступный в его книге 'Грамотное программирование', и вероятно в другом месте также). Это обсуждает, среди других вещей, управляемые способы убежать из циклов, и (не использование термина) loop-and-a-half оператор.

Ada также обеспечивает конструкции цикличного выполнения, включая [1 110]

loopname:
    loop
        ...
        exit loopname when ...condition...;
        ...
    end loop loopname;

, код исходного вопроса подобен этому в намерении.

Одно различие между ссылаемым, ТАКИМ ОБРАЗОМ, объект и это являются 'заключительным повреждением'; это - однократный цикл, который использует повреждение для выхода из цикла рано. Были вопросы на том, является ли это хорошим стилем также - у меня нет перекрестной ссылки под рукой.

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

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

или "повторением до", которое сделано в подобном языку C с

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

, Если любая из этих работ случаев, используйте их.

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

ТОГДА И ТОЛЬКО ТОГДА использование некоторое время (1):

while(1) {
   accept connection
   fork child process
}

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

while(1) { // or for(;;)
   // do some stuff
   if (condition met) break;
   // otherwise do more stuff.
}

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

Короче говоря, я с Вашим коллегой в самом простом случае, но, в то время как (верный) {...} Весьма распространено.

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

• It’s более простой, так как Вам не нужен другой тест в коде.
• It’s легче читать, начиная с Вас don’t должны отправиться на охоту для повреждения в цикле.
• You’re, перестраивающий колесо. Смысл того, в то время как должен сделать что-то пока тест, верен. Почему ниспровергают это путем помещения условия повреждения где-то в другом месте?

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

Когда-то Вам нужен бесконечный цикл, например, слушающий на порте или ожидающий соединения.

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

Первое в порядке, если существует много способов повредиться от цикла, или если условия повреждения нельзя выразить легко наверху цикла (например, содержание цикла должно работать на полпути, но другая половина не должна работать на последнем повторении).

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

Javier сделал интересный комментарий к моему более раннему ответу (одно заключение в кавычки Wordsworth):

я думаю, в то время как (верный) {} более 'чистая' конструкция, чем в то время как (условие) {}.

и я не мог ответить соответственно в 300 символах (извините!)

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

Так, с целью сокращения сложности, позволяют мне ответить Javier с точки зрения полноты и силы, а не чистоты.

я думаю об этом фрагменте кода:

while (c1) {
    // p1
    a1;
    // p2
    ...
    // pz
    az;
}

как выражение двух вещей одновременно:

1. (все) тело будет повторено целых c1, остается верным, и
2. в точке 1, где a1 выполняется, c1 , гарантировал для содержания.

различием является одна из перспективы; первый из них имеет отношение к внешнему, динамическому поведению всего цикла в целом, в то время как второе полезно для понимания внутренней, статической гарантии, на которую я могу рассчитывать при размышлении [приблизительно 116] в частности. Конечно, результирующий эффект a1 может делать недействительным c1, требуя, чтобы я думал тяжелее о том, на что я могу рассчитывать в точке 2, и т.д.

, давайте поместим определенный (крошечный) пример на месте для размышления об условии и первом действии:

while (index < length(someString)) {
    // p1
    char c = someString.charAt(index++);
    // p2
    ...
}

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

"внутренняя" проблема - то, что нам гарантируют это, следующий момент действия 1 будет законен, поэтому при чтении кода в точке 2 я могу думать о том, что делается с символьным I значения, знают , был по закону получен. (Мы не можем даже оценить условие, если someString пустой указатель касательно, но я также предполагаю, что мы приняли меры против этого в контексте вокруг этого примера!)

Напротив, цикл формы:

while (true) {
    // p1
    a1;
    // p2
    ...
}

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

На внутреннем уровне, я имею абсолютно никакой явная гарантия о любых обстоятельствах, которые могут содержать в точке 1. Условие true, который, конечно, верен везде, является самым слабым оператором о том, что мы можем знать в любой точке в программе. Понимание предварительных условий действия является очень ценной информацией при попытке думать о том, что выполняет действие!

Так, я предполагаю, что while (true) ... идиома является намного более неполной и слабой, и поэтому более сложной, чем [1 117] согласно логике, которую я описал выше.

в то время как (верный) мог бы иметь смысл, если у Вас есть много операторов, и Вы хотите остановиться, если сбой

 while (true) {
     if (!function1() ) return;   
     if (!function2() ) return;   
     if (!function3() ) return;   
     if (!function4() ) return;  
   }

лучше, чем

 while (!fail) {
     if (!fail) {
       fail = function1()
     }           
     if (!fail) {
       fail = function2()
     }  
     ........

   }

Я предпочитаю

while(!<some condition>) {
    //do something
}

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

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

В случае многих break точки я заменил бы их [1 112]

while( !<some condition> ||
       !<some other condition> ||
       !<something completely different> ) {
    //do something
}

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

Когда можно записать код в форме

while (condition) { ... }

или

while (!condition) { ... }

с [1 116] никакие выходы (break, continue, или goto) в теле , та форма предпочтена, потому что кто-то может считать код, и понимают условие завершения только путем рассмотрения заголовка . Это хорошо.

for (;;) { ... }