Оправдывает ли это заявления goto?

Я столкнулся с этим вопросом секунду назад, и я извлекаю часть материала оттуда: есть ли название для конструкции 'break n'?

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

for (i = 0; i < 10; i++) {
    bool broken = false;
    for (j = 10; j > 0; j--) {
        if (j == i) {
            broken = true;
            break;
        }
    }
    if (broken)
        break;
}

Я знаю, что в учебниках нравится говорить, что заявления goto - это дьявол, и я их совсем не люблю, но оправдывает ли это исключение из правила?

Я ищу ответы, которые касаются n-вложенных циклов.

ПРИМЕЧАНИЕ. Независимо от того, отвечаете ли вы «да», «нет» или где-то посередине, ответы совершенно не принимаются . Особенно, если ответ «нет», то предоставьте хорошую, законную причину (почему, в любом случае, это не слишком далеко от правил Stack Exchange).

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

Вы утверждаете, что хотели, чтобы внешний цикл продолжался столько же, сколько i < 10самый внутренний, чтобы продолжался до тех пор j > 0.

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

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

bool alsoThis = true;
for (i = 0; i < 10 && alsoThis; i++)
{    
    for (j = 10; j > 0 && alsoThis; j--)
    {
        if (j == i)
        {
            alsoThis = false;
        }
    }
}

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

bool isBroken() {
    for (i = 0; i < 10; i++)
        for (j = 10; j > 0; j--)
            if (j == i) return true;

    return false;
}

Нет, я не думаю, что это gotoнеобходимо. Если вы напишите это так:

bool broken = false;
saved_i = 0;
for (i = 0; i < 10 && !broken; i++)
{
    broken = false;
    for (j = 10; j > 0 && !broken; j--)
    {
        if (j == i)
        {
            broken = true;
            saved_i = i;
        }
    }
}

Наличие &&!brokenна обоих циклах позволяет вам выйти из обоих циклов, когда i==j.

Для меня такой подход предпочтительнее. Условия цикла чрезвычайно ясно: i<10 && !broken.

Работающую версию можно увидеть здесь: http://rextester.com/KFMH48414

Код:

public static void main(String args[])
{
    int i=0;
    int j=0;
    boolean broken = false;
    for (i = 0; i < 10 && !broken; i++)
    {
        broken = false;
        for (j = 10; j > 0 && !broken; j--)
        {
            if (j == i)
            {
                broken = true;
                System.out.println("loop breaks when i==j=="+i);
            }
        }
    }
    System.out.println(i);
    System.out.println(j);
}

Выход:

разрывы цикла, когда я == j == 1
2
0

Краткий ответ «это зависит». Я выступаю за выбор в отношении разборчивости и понятности вашего кода. Путь перехода может быть более разборчивым, чем изменение условия, или наоборот. Вы также можете принять во внимание принцип наименьшего удивления, руководство, используемое в магазине / проекте, и согласованность кодовой базы. Например, goto to switch или для обработки ошибок - обычная практика в кодовой базе ядра Linux. Также обратите внимание, что у некоторых программистов могут возникнуть проблемы с чтением вашего кода (либо возникшие с мантрой «goto is evil», либо просто не изученные, потому что их учитель так считает), и некоторые из них могут даже «судить вас».

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

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

Подумайте о вашем будущем рецензенте: ему / ей придется подумать: «Этот человек плохой кодер или это действительно тот случай, когда goto стоило того? Позвольте мне потратить 5 минут, чтобы решить это для себя или исследовать его на интернет «. С какой стати вы так поступаете со своим будущим кодером, если не можете использовать goto полностью?

В общем, этот менталитет применяется ко всему «плохому» коду и даже определяет его: если он работает сейчас и хорош в этом случае, но прилагает усилия для проверки его правильности, что в эту эпоху всегда будет делать goto, то не сделай это.

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

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

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

Между прочим, лучшая дискуссия, которую я видел, - это « Завершенный код» Стива Макконнелла . Если вам нравится критически относиться к этим проблемам, я настоятельно рекомендую читать, даже прикрытие, несмотря на его необъятность.

TLD; DR: нет конкретно, да вообще

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

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

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

Я не думаю, что этот случай оправдывает исключение, так как это можно записать так:

def outerLoop(){
    for (i = 0; i < 10; i++) {
        if( broken?(i) )
          return; // broken
    }
}

def broken?(i){
   for (j = 10; j > 0; j--) {
        if (j == i) {
            return true; // broken
        }
   }
   return false; // not broken
}