Pourquoi les instructions "continue" sont-elles mauvaises en JavaScript ?

Question

Dans le livre Javascript : Les bons côtés de Douglas Crockford, c'est tout ce que l'auteur a à dire sur la déclaration continue :

El continue saute au début de la boucle. Je n'ai jamais vu un morceau de code qui n'ait pas été amélioré en le remaniant pour supprimer l'instruction continue déclaration.

Ça me perturbe vraiment. Je sais que Crockford a des opinions très tranchées sur JavaScript, mais cela me semble tout à fait faux.

Tout d'abord, continue fait plus que simplement sauter au sommet d'une boucle. Par défaut, il passe également à l'itération suivante. L'affirmation de Crockford n'est-elle donc pas une information complètement fausse ?

Plus important encore, je ne comprends pas entièrement pourquoi continue serait même considéré comme mauvais. Ce post fournit ce qui semble être l'hypothèse générale : Pourquoi continuer à l'intérieur d'une boucle est une mauvaise idée ?

Bien que je comprenne comment continue peut rendre le code difficile à lire dans certains cas, je pense qu'il est tout aussi probable qu'il puisse rendre le code plus lisible. Par exemple :

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);
        }
    }
}

Cela pourrait être refactorisé en :

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 n'est pas particulièrement bénéfique dans cet exemple spécifique, mais il démontre le fait qu'il réduit la profondeur d'imbrication. Dans un code plus complexe, cela peut potentiellement améliorer la lisibilité.

Crockford ne fournit aucune explication quant à la raison pour laquelle continue ne devrait pas être utilisé. Y a-t-il une signification plus profonde derrière cette opinion qui m'échappe ?

Answer 1

Cette déclaration est ridicule. continue peut être abusé, mais il est souvent aide la lisibilité.

Utilisation typique :

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

    some_provisional_work_that_is_almost_always_needed();

    if (!further_tests()) continue;

    do_expensive_operation();
}

L'objectif est d'éviter le code "lasagna", où les conditionnels sont profondément imbriqués.

Modifié pour ajouter :

Oui, c'est finalement subjectif. Voici ma métrique pour décider.

Modifié une dernière fois :

Cet exemple est trop simple, bien sûr, et vous pouvez toujours remplacer les conditionnels imbriqués par des appels de fonction. Mais dans ce cas, vous devrez peut-être passer des données par référence dans les fonctions imbriquées, ce qui peut créer des problèmes de refactoring au moins aussi graves que ceux que vous essayez d'éviter.

Answer 2

Je suis personnellement de l'autre côté que la majorité ici. Le problème ne vient généralement pas de l'exposé continue mais avec des modèles plus profondément imbriqués, où les chemins de code possibles peuvent devenir difficiles à voir.

Mais même votre exemple avec un continue ne montre pas une amélioration qui, à mon avis, est justifiable. D'après mon expérience, quelques continue Les déclarations sont un cauchemar à refactoriser plus tard (même pour les langages statiques mieux adaptés à la refactorisation automatisée comme Java, surtout lorsque quelqu'un y met plus tard break aussi).

J'ajouterai donc un commentaire à la citation que vous avez faite :

Refactoring pour supprimer continue augmente votre capacité de réingénierie.

Et les boucles internes sont vraiment de bons candidats pour, par exemple. fonction d'extraction . Un tel remaniement est effectué lorsque la boucle interne devient complexe, puis continue peut le rendre douloureux.

Ce sont mes opinions honnêtes après avoir travaillé professionnellement sur des projets JavaScript en équipe, les règles dont parle Douglas Crockford montrent vraiment leurs mérites.

Answer 3

Douglas Crockford est peut-être de cet avis parce qu'il ne croit pas à l'affectation au sein d'un conditionnel. En fait, son programme JSlint ne vous permet même pas de le faire, même si Javascript le fait. Il n'écrirait jamais :

Exemple 1

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

    doSomething(rec);
}

mais, je suppose qu'il serait écrire quelque chose comme :

Exemple 2

rec = getrec();

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

    rec = getrec();
}

Les deux fonctionnent, mais si vous mélangez accidentellement ces styles, vous obtenez une boucle infinie :

Exemple 3

rec = getrec();

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

    rec = getrec();
}

Ça pourrait être une partie de la raison pour laquelle il n'aime pas continuer.

Answer 4

Continue est un outil extrêmement utile pour économiser des cycles de calcul dans les algorithmes. Bien sûr, il peut être mal utilisé, mais il en va de même pour tous les autres mots-clés ou approches. Lorsque l'on s'efforce d'obtenir des performances, il peut être utile d'adopter une approche inverse de la divergence des chemins avec une instruction conditionnelle. Un continue peut faciliter l'inverse en permettant de sauter les chemins les moins efficaces lorsque cela est possible.

Answer 5

Personnellement, je n'ai jamais entendu parler d'une mauvaise utilisation de l'instruction continue. Il est vrai qu'elle pourrait (la plupart du temps) être facilement évitée, mais il n'y a pas de raison de no l'utiliser. Je trouve que les boucles peuvent être beaucoup plus propres et plus lisibles avec des instructions continues en place.