Почему ошибки «продолжить» плохо в JavaScript?

Question

В книге Javascript: The Good Parts Дуглас Crockford, все это автор должен сказать о заявлении продолжения:

continue оператор переходит к началу цикла. Я никогда не видел фрагмент кода, который не был улучшен путем реорганизации его, чтобы удалить оператор continue.

Это действительно смущает меня. Я знаю, что у Крокфорда есть очень упрямые взгляды на JavaScript, но это звучит совершенно неправильно для меня.

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

Что еще более важно, я не совсем понимаю, почему continue будет считаться плохим. Это сообщение обеспечивает то, что, как представляется, общее предположение: Why is continue inside a loop a bad idea?

Хотя я понимаю, как continue может сделать код трудно читать в некоторых случаях, я думаю, что это так же, как вероятность того, что он может сделать код более читаемым. Например:

var someArray=['blah',5,'stuff',7]; 
for(var i=0;i<someArray.length;i++){ 
    if(typeof someArray[i]==='number'){ 
     for(var j=0;j<someArray[i];j++){ 
      console.log(j); 
     } 
    } 
} 

Это может быть переработан в:

var someArray=['blah',5,'stuff',7]; 
for(var i=0;i<someArray.length;i++){ 
    if(typeof someArray[i]!=='number'){ 
     continue; 
    } 
    for(var j=0;j<someArray[i];j++){ 
     console.log(j); 
    } 
} 

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

Crockford не дает никаких объяснений относительно того, почему continue не должно использоваться, так что имеет место какое-то более глубокое значение за этим мнением, что мне не хватает?

Answer 1

Заявление нелепо. continue можно злоупотреблять, но часто помогает читаемость.

Типичное применение:

for (somecondition) 
{ 
    if (!firsttest) continue; 

    some_provisional_work_that_is_almost_always_needed(); 

    if (!further_tests()) continue; 

    do_expensive_operation(); 
} 

Цель состоит в том, чтобы избежать код «лазаньи», где вы должны глубоко вложенными условными.

Edited добавить:

Да, это в конечном счете, субъективный характер. Here's my metric for deciding.

Отредактировано последний раз:

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

Answer 2

Лично я никогда не слышал ничего плохого в использовании инструкции continue.Это правда, что его можно (в большинстве случаев) легко избежать, но нет причин для использования не. Я нахожу, что петли могут быть более чистыми и более читабельными с продолжением утверждений.

Answer 3

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

Answer 4

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

Но даже ваш пример с одним continue не показывает улучшения, на мой взгляд, оправданным. Из моего опыта несколько заявлений continue - это кошмар для рефакторинга (даже для статических языков, более подходящих для автоматического рефакторинга, такого как Java, особенно когда кто-то позже ставит там break).

Таким образом, я хотел бы добавить комментарий к цитате вы дали:

Refactoring удалить continue заявление inreases вашей дальнейшей возможности рефакторинга, рефакторинга.

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

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

Answer 5

Douglas Crockford может чувствовать себя так, потому что он не верит в назначение в условном выражении. Фактически, его программа JSlint даже не позволяет вам это делать, даже если Javascript это делает. Он никогда бы не написать:

Пример 1

while (rec = getrec()) 
{ 
    if (condition1(rec)) 
     continue; 

    doSomething(rec); 
} 

, но я предполагаю, что он бы написать что-то вроде:

Пример 2

rec = getrec(); 

while (rec) 
{ 
    if (!condition(rec)) 
     doSomething(rec); 

    rec = getrec(); 
} 

Оба из этих работ, но если вы случайно смешаете эти yles вы получите бесконечный цикл:

Пример 3

rec = getrec(); 

while (rec) 
{ 
    if (condition1(rec)) 
     continue; 

    rec = getrec(); 
} 

Это может быть частью того, почему он не любит по-прежнему.

Answer 6

На самом деле, из всего анализа, кажется: - (? И есть может некоторый прирост производительности)

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

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