Continuer Considéré comme nocif ?[fermé]

Question

Les développeurs devraient-ils éviter d'utiliser continuer en C# ou son équivalent dans d'autres langages pour forcer la prochaine itération d'une boucle ?Les arguments pour ou contre se chevaucheraient-ils avec les arguments sur Aller à?

Answer 1

Je pense qu'il devrait y avoir davantage d'utilisation de continue !

Trop souvent, je tombe sur du code comme :

for (...)
{
   if (!cond1)
   {
      if (!cond2)
      {
          ... highly indented lines ...
      }
   }
}

au lieu de

for (...)
{
   if (cond1 || cond2)
   {
      continue;
   }

   ...
}

Utilisez-le pour rendre le code plus lisible !

Answer 2

Est continue pas plus nocif que, disons, break?

Au contraire, dans la majorité des cas où je le rencontre/l'utilise, je trouve que cela rend le code plus clair et moins ressemblant à un spaghetti.

Answer 3

Vous pouvez écrire du bon code avec ou sans continuer et du mauvais code avec ou sans continuer.

Il y a probablement un certain chevauchement avec les arguments concernant goto, mais en ce qui me concerne, l'utilisation de continue équivaut à utiliser des instructions break (dans des boucles) ou une instruction return depuis n'importe où dans le corps d'une méthode - si elle est utilisée correctement, elle peut simplifier le code. (moins susceptible de contenir des bugs, plus facile à maintenir).

Answer 4

Il n’y a pas de mots-clés nuisibles.Il n’y a que des utilisations nuisibles.

Goto n'est pas nuisible en soi, ni continue.Il faut les utiliser avec précaution, c'est tout.

Answer 5

Si continuer pose un problème de lisibilité, il est probable que vous ayez d'autres problèmes.Par exemple, d’énormes quantités de code dans une boucle for.Si vous devez écrire de grandes boucles for, j'essaierais de m'en tenir à l'utilisation de continue près du haut de la boucle for.Sinon, un continue enfoui profondément au milieu d'une boucle for peut facilement être manqué.

Answer 6

J'aime utiliser continue au début des boucles pour gérer des conditions if simples.

Pour moi, cela rend le code plus lisible puisqu'il n'y a pas d'imbrication supplémentaire et vous pouvez voir que j'ai explicitement traité ces cas.

Est-ce la même raison pour laquelle j'utiliserais un goto ?Peut-être.Je les utilise parfois pour des raisons de lisibilité et pour arrêter l'imbrication du code, mais je les utilise généralement davantage pour le nettoyage/la gestion des erreurs.

Answer 7

Je dirais:"ça dépend".

Si vous avez un code de boucle raisonnablement petit (où vous pouvez voir l'intégralité du code de boucle sans faire défiler), vous pouvez généralement utiliser une suite.

Cependant, si le corps de la boucle est volumineux (par exemple en raison d'un gros commutateur) et qu'il y a du code de suivi (par exemple sous le commutateur), vous pouvez facilement introduire des bugs en ajoutant un continue et en sautant parfois ce code.J'ai rencontré cela au cœur d'un interpréteur de bytecode, où certains codes d'instrumentation n'étaient parfois pas exécutés en raison d'une continuation dans certaines branches de cas.

Cela peut être un cas quelque peu construit artificiellement, mais j'essaie généralement d'éviter de continuer et d'utiliser un if (mais pas d'imbrication trop profonde comme dans l'exemple de code de Rob).

Answer 8

Je ne pense pas que continuer puisse être aussi difficile que goto puisque continuer ne déplace jamais l'exécution hors du bloc de code dans lequel elle se trouve.

Answer 9

Si vous parcourez n'importe quel type d'ensemble de résultats et effectuez des opérations sur lesdits résultats, par exemple dans un pour chacun, et si un résultat particulier a causé un problème, c'est plutôt utile pour capturer une erreur attendue (via try-catch), en le connectant et en passant au résultat suivant via Continuer.Continuer est particulièrement utile, à mon avis, pour les services sans surveillance qui effectuent des travaux à des heures impaires, et une exception ne devrait pas affecter l'autre nombre x d'enregistrements.

Answer 10

1. Utiliser continue au début d'une boucle pour éviter une itération sur des éléments inutiles n'est pas nuisible et peut être très utile, mais l'utiliser au milieu de ifs et d'elses imbriqués peut transformer le code de la boucle en un labyrinthe complexe, à comprendre et à valider.

2. Je pense que son évitement d'utilisation est également le résultat d'un malentendu sémantique.Les personnes qui ne voient/écrivent jamais le mot-clé 'continue' sur leur code, lorsqu'elles voient un code avec continue peuvent l'interpréter comme "la continuation du flux naturel".Si au lieu de continuer nous avions suivant, par exemple, je pense que davantage de personnes apprécieraient cette précieuse fonctionnalité de curseur.

Answer 11

goto peut être utilisé comme continue, mais pas l'inverse.

Vous pouvez "aller" n'importe où, interrompant ainsi arbitrairement le contrôle de flux.

Ainsi continuez, ce n’est pas aussi nocif.

Answer 12

D'autres l'ont laissé entendre...mais continuer et rompre sont imposés par le compilateur et ont leurs propres règles associées.Goto n'a pas de telles limitations, même si l'effet net pourrait être presque le même, dans certaines circonstances.

Je ne considère pas que continue ou break soit nuisible en soi, même si je suis sûr que l'un ou l'autre peut être mal utilisé d'une manière qui ferait bâillonner tout programmeur sensé.

Answer 13

Je dirais oui.Pour moi, cela interrompt simplement le « flux » d'un morceau de code écrit de manière fluide.

Un autre argument pourrait également être que si vous vous en tenez aux mots-clés de base pris en charge par la plupart des langages modernes, alors le déroulement de votre programme (sinon la logique ou le code) pourrait être porté dans n'importe quel autre langage.Avoir un mot-clé non pris en charge (c'est-à-dire continuer ou aller à) briserait cela.

C'est vraiment plus une préférence personnelle, mais je n'ai jamais eu à l'utiliser et je ne le considère pas vraiment comme une option lorsque j'écris du nouveau code.(identique à Goto.)

Answer 14

En ce qui concerne ce programmeur, Imbriqué si/sinon considéré comme nocif.

Answer 15

Continuer est une fonction très utile dans la plupart des langages, car elle permet d'ignorer des blocs de code dans certaines conditions.

Une alternative serait d'utiliser des variables booléennes dans les instructions if, mais celles-ci devraient être réinitialisées après chaque utilisation.

Answer 16

continuer me semble mal.une pause vous sort de là, mais continuer semble être juste des spaghettis.

D'un autre côté, vous pouvez émuler continue avec break (au moins en Java).

for (String str : strs) contLp: {
    ...
       continue contLp;
    ...
}

continuer peut être utile dans certaines circonstances, mais cela me semble toujours sale.

for (char c : cs) {
    final int i;
    if ('0' <= c && c <= '9') {
        i = c - '0';
    } else if ('a' <= c && c <= 'z') {
        i = c - 'a' + 10;
    } else {
        continue;
    }
    ... use i ...
}

Answer 17

Je crois que l’argument fondamental contre la poursuite est qu’il est plus difficile de PROUVER que le code est correct.C’est une preuve au sens mathématique.Mais cela n'a probablement pas d'importance pour vous, car personne n'a les ressources nécessaires pour « prouver » un programme informatique très complexe.

Entrez dans les outils d'analyse statique.Vous pourriez leur rendre les choses plus difficiles...

Et le goto, cela ressemble à un cauchemar pour les mêmes raisons mais à n'importe quel endroit aléatoire du code.