Вы рассматриваете эту технику “ПЛОХО”?

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

Я думаю, что люди не честны здесь.

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

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

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

, Почему не просто используют

if(isGood)
{
...Execute more code
}

?

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

При разделении кода между , если (! isGood) повреждение; в отдельные функции, можно закончить с десятками функций, содержащих просто нескольких строк, так, чтобы деятели не упростили что-либо. Я не мог использовать возврат , потому что я не готов оставить функцию, существует все еще материал, который я хочу сделать там. Я признаю, что, вероятно, должен просто согласиться отдельный если (isGood) {...} условие для каждой части кода, которую я хочу выполнить, но иногда который привел бы к БОЛЬШОМУ КОЛИЧЕСТВУ фигурных скобок. Но я предполагаю, что признаю, что людям действительно не нравится тот тип конструкции, таким образом, условия для всего вьются!
спасибо за Ваши ответы.

Я думаю, что нет ничего в основном неправильно с техникой. Я думаю, что удостоверился бы, что bool называют чем-то более описательным, чем isGood. Хотя, теперь, когда я смотрю на него, почему был бы он не работать для помещения всего кода, который в курсе в сингл если (! isGood) блок? Цикл только выполняется однажды.

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

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

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

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

if (condition1(...) && condition2(...) && condition3(...) && ... && conditionN(...)) {
    // code that ought to run after all conditions
};
// code that ought to run whether all conditions are met or not

Затем я думаю, что это было бы более "читаемым" и более идиоматичным. Таким образом, можно сделать функции как:

bool conditionN(...) {
    if (!real_condition) return false;
    // code that ought to run
    return true;
};

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

Что относительно функционального подхода?

        void method1()
        {
            ... some code
            if( condition )
                method2();
        }

        void method2()
        {
            ... some more code
            if( condition )
                method3();
        }

        void method3()
        {
            ... yet more code
            if( condition )
                method4();
        }

Если Ваш код делает что-то другое, чем простое значение конструкций на месте, это - хороший знак, которым Вы рисковали в "милую" территорию.

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

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

Я сказал бы, что Вашим решением может быть правильное решение, но оно зависит. Paul Tomblin отправил ответ, который лучше (серия если трубы)..., если он может использоваться.

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

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

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

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

Мне то, что Вы делаете, плохо таким количеством способов. Цикл может быть заменен путем помещения того кода в методе.

я лично полагаю этому, если необходимо поместить a! перед Вашими условиями затем Вы ищете неправильную вещь. Поскольку удобочитаемость делает Ваше булево соответствие, на что Вы проверяете. Вы действительно проверяете, существует ли ошибка или некоторое плохое состояние, таким образом, я предпочел бы:

If (isError)
{
   //Do whatever you need to do for the error and
   return;
}

If (!isGood)
{
  //Do something
}

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

Одна из первых вещей я работал над, 28 лет назад была программа Фортрана, которая всегда должна была проверять, было ли графическое доступное устройство. Кто-то принял главное решение назвать булевскую переменную для этого LNOGRAF, поэтому если бы было графическое устройство, доступное, то это было бы ложью. Я полагаю, что это было установлено этот путь из-за ложной эффективности, проверка на устройство возвратила нуль, если было графическое устройство. Всюду по коду должны были видеть все проверки, было ли графическое устройство доступно. Это было полно:

, Если (.NOT. LNOGRAF)

я не думаю, что был сингл:

, Если (LNOGRAF)

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

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

    /* This is a one-cycle loop that simplifies error handling */
    do
    {
        ...modestly complex code, including a nested loop...
    } while (0);

Это находится в C, а не C++ - таким образом, исключениями не является опция. Если бы я использовал C++, то я полагал бы, что серьезно исключения использования обрабатывают исключения. Повторная тестовая идиома, предложенная Jeremy, также разумна; я использовал это более часто. RAII помог бы мне значительно, также; к сожалению, C не поддерживает это легко. И использование большего количества функций помогло бы. Обработка повреждений из вложенного цикла сделана повторным тестом.

я не классифицировал бы его как большой стиль; я автоматически не категоризировал бы его как "ПЛОХО".

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

У меня нет проблемы с этим, пока код читаем.

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

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

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

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

Осуществить рефакторинг. Чистое решение будет состоять в том, чтобы в большинстве случаев разделить этот код на меньшую функцию помощника, из которой можно возвратиться вместо того, чтобы убегать из not-actually-a-loop.

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

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

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

// Code

if (bad_thing_happened) goto catch;

// More code

if (bad_thing_happened) goto catch;

// Even more code

finally:

// This code is executed in any case
// whether we have an exception or not,
// just like finally statement in other
// languages

return whatever;

catch:

// Code to handle bad error condition

// Make sure code tagged for finally
// is executed in any case
goto finally;

За исключением факта, которые ловят и наконец имеют противоположный порядок, мне не удается видеть, почему этот код должен быть ПЛОХИМ просто, потому что он использует goto, если реальный код попытки/выгоды/наконец работает точно как это и просто не использует goto. Это не имеет никакого смысла. И таким образом мне не удается видеть, почему Ваш код должен быть отмечен как ПЛОХО.

То, что Вы пытаетесь сделать, является нелокальным восстановлением после отказа. Это - то, для чего goto. Используйте его. (на самом деле это - то, что обработка исключений для - но если Вы не можете использовать это, 'goto', или 'setjmp/longjmp' являются следующей лучшей вещью).

Этот шаблон, if(succeeded(..)) шаблон, и 'goto очистка', все 3 семантически и структурно эквивалентны. Используйте, какой бы ни каждый наиболее распространен в Вашем проекте кода. В непротиворечивости существует много значения.

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

do{
   bool isGood = true;
   .... some code
   if(!isGood)
       break;
   .... some more code
   for(....){
      if(!isGood)
          break; // <-- OOPS, this will exit the 'for' loop, which 
                 //  probably isn't what the author intended
      .... some more code
   }
} while(false);
..... some other code, which has to be executed.

Ни goto cleanup, ни if(succeeded(..)) имеют это удивление, таким образом, я поощрил бы использовать один из этих двух вместо этого.

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

Как насчет того, чтобы использовать более обычные функции языка как функции?

bool success = someSensibleFunctionName();

if(success)
{
   ...
}

someCommonCodeInAnotherFunction();

public bool Method1(){ ... }
public bool Method2(){ ... }

public void DoStuff(){
    bool everythingWorked = Method1() && Method2();
    ... stuff you want executed always ...
}

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

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

Вы в значительной степени просто маскируете "goto" как поддельный цикл. Нравится ли Вам gotos или нет, Вы так же, как далеко впереди использовали бы реальный явный goto.

Лично, я просто записал бы это как

bool isGood = true;

   .... some code

   if(isGood)
   {
   .... some more code
   }

   if(isGood)
   {
   .... some more code
   }

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

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

Это является замысловатым и сбивает с толку, я сразу фрагментировал бы его.

Рассматривают эту альтернативу:

private void DoSomething()
{
   // some code
   if (some condition)
   {
      return;
   }
   // some more code
   if (some other condition)
   {
      return;
   }
   // yet more code
}

Также рассматривают разбивание кода выше больше чем в один метод.

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

someMethod()
{
   .... some code

   if(!isGood)
       return;

   .... some more code

   if(!isGood)
       return;

   .... some more code

 }