Les else while
entretoises sans intervention sont-elles considérées comme «sûres» pour la maintenance?
Écrire du if-else
code sans accolades comme ci-dessous ...
if (blah)
foo();
else
bar();
... comporte un risque car le manque d'accolades permet de changer très facilement la signification du code par inadvertance.
Cependant, ci-dessous est-il également risqué?
if (blah)
{
...
}
else while (!bloop())
{
bar();
}
Ou else while
sans accolades est-il considéré comme «sûr»?
else while
c'est dégueu. J'utiliseraiselse { while (condition) { ... } }
.if
n'est évalué qu'une seule fois, maiswhile
dénote une boucle, donc la connexion des deux me donne un sentiment non étayé que celaif
fait partie de la boucle ... en quelque sorte ...else
clause, vous voulez fairewhile
et faire quelque chose de plus? Utilisez simplement des accolades, s'il vous plaît.Réponses:
Cela me rappelle ce code:
Chaque fois que vous combinez deux types de blocs, oubliant les accolades et n'augmentant pas l'indentation, vous créez du code très difficile à comprendre et à maintenir.
la source
C'est peut-être parce que j'ai appris mon métier (il y a longtemps ) en utilisant la méthode Jackson Entity Structure Diagram , mais je souscris à l'idée que le seul terme correct sans accolade après un
if
ou unelse
est un suivantif
(c'est-à-dire autoriser uneelse if
échelle)Tout autre élément (sans jeu de mots) laisse la possibilité de malentendus et / ou de problèmes de maintenance. C'est l'aspect central de l'idée que les PO sont «dangereux».
Je serais également très hésitant à inclure le
while()
sur la même ligne que leelse
- qu'il soit contreventé ou non. Cela ne me semble pas juste ... l'absence de masques d'indentation supplémentaires que c'est laelse
clause. Et le manque de clarté crée des malentendus (voir ci-dessus).Donc, dans l'exemple, je conseillerais / recommanderais fortement (et insisterais, dans mon équipe) sur:
Bien sûr, je m'attendrais également à voir des commentaires appropriés aussi.
-- Modifier --
Récemment, Apple a souffert d'une vulnérabilité SSL, causée par un correctif de maintenance médiocre - qui a ajouté une deuxième ligne à une seule ligne sans contreventement. Mettons donc de côté l'idée que les lignes simples sans accolade sont OK?
la source
else while
je ne remarquerais probablement même pas qu'il y avait une boucle dans un survol rapide du code, surtout si la condition que je recherchais était satisfaite par le si.else while
sans accolades intervenir considérés comme « sûrs » ?On m'a toujours appris à tout garder entre accolades, en retrait et commenté. Je pense que c'est beaucoup plus facile à lire et à repérer les erreurs. Personnellement, je pense que la modularité est la clé, donc j'écrirais toujours le code comme ceci:
la source
Je voudrais extraire la méthode et la faire
Voir l'approche "extraire la méthode" expliquée sur le site du catalogue de refactorisation :
la source
Je le considérerais comme une mauvaise habitude de codage. Parfois, cela fonctionne parfaitement bien et vous n'aurez aucun problème pour compiler et exécuter le code. À d'autres moments, cela peut provoquer de graves bogues et vous finirez par passer des heures à le corriger.
Il est toujours recommandé de modulariser votre code. Si vous devez mettre une boucle while dans une autre partie, placez-la dans un bloc afin que les autres, lorsqu'ils travaillent sur votre code, puissent facilement comprendre la logique.
C'est une bonne pratique de mettre du code en blocs. Cela le rend plus simple et plus facile à comprendre et à déboguer également.
la source
Cela pourrait être bien si cela reste simple comme ça, bien que personnellement je ne l'aime pas et ma préférence est d'utiliser des accolades même pour les blocs de code if / else les plus simples. C'est juste plus propre pour moi.
Cependant, lorsque cela devient compliqué, c'est lorsque vous avez imbriqué if / else en boucle avec des accolades, d'autres sans. Une boucle While au milieu de tous ces spaghettis! J'ai si mal travaillé avec du code et c'est un cauchemar à déboguer et à comprendre. Cela découle du premier point, c'est bien quand cela reste simple et que vous en êtes satisfait, mais ensuite d'autres programmeurs viennent et y ajoutent des choses, probablement un si autre dans la boucle while. Si c'est écrit en premier lieu, il y a moins de chances que cela se produise.
Le but est de clarifier les choses afin que les autres programmeurs puissent voir en un coup d'œil ce qui est bien ou mal. Écrivez le code de sorte que le motif soit correct et ne fasse pas de bruit.
Le revers de la médaille est que je pourrais peut-être voir certaines personnes affirmer que, dans certains cas, cela se lit bien. Si j'ai la ressource dont j'ai besoin pour faire ce traitement autrement pendant que j'attends quelque chose, faites-le. Même pour moi, il n'y a toujours pas de différence dans l'imbrication de la boucle while à l'intérieur du bloc else.
la source
Eh bien, malgré que tout le monde se disputent sur l'utilisation d'appareils orthodontiques et semblent les aimer, je préfère en fait le contraire. Je n'utilise des accolades que lorsque je le dois car je le trouve plus lisible et concis sans.
... Je trouve ce "
else while(...)
" remarquablement lisible! Il se lit même comme un anglais ordinaire! Mais je suppose que les gens trouveront tous ça étrange parce que c'est pour le moins inhabituel.En fin de compte, nous avons tous tendance à le rendre à l'épreuve des idiots avec des accolades ... parce que, eh bien, vous savez.
la source
else while(...) bar();
quelque chose commeelse while(...) foobar(); bar();
:)Je mets toujours des accolades, juste parce que vous pourriez ajouter une autre ligne lorsque vous êtes pressé, la mettre en retrait, oublier les accolades et vous gratter la tête de ce qui se passe. Je garde le support d'ouverture sur la même ligne, mais cela n'a pas d'importance. Dans les deux cas, il vaut mieux les avoir.
la source
Qu'est-ce qui ne va pas avec les accolades que tant de gens essaient d'éviter de les écrire?
Quel problème résout exactement
else while
?Les accolades sont bon marché et bonnes, et elles rendent l'intention du code évidente et simple, par opposition à intelligent et plein d'esprit.
Citant la philosophie Unix:
Règle de clarté: la clarté est meilleure que l'intelligence.
la source
Il n'y a rien de mal à
tout comme il n'y a rien de mal à
dans les bonnes circonstances (vos circonstances peuvent varier, mais ce style particulier est mieux utilisé lorsque vous avez beaucoup de code répétitif - alors la vue de chaque ligne est plus importante que l'indentation stylistique)
Mais si vous choisissez une façon, respectez-la - la cohérence est la règle. Donc, votre deuxième exemple est très mauvais, car l'expression if avait des crochets pour son instruction, l'instruction while devrait être à l'intérieur des crochets de la clause else, pas à l'extérieur.
d'ailleurs j'ai déjà vu ce code:
et il a été écrit par le standard de codage nazi lui-même (qui a insisté sur les crochets pour tout).
la source
Les IDE modernes peuvent facilement être configurés pour reformater (y compris supprimer ou ajouter des accolades inutiles) et / ou réindenter le code lors de l'enregistrement d'un fichier. Ainsi, votre exemple ressemblerait automatiquement par exemple
L'indentation rend toujours la nidification facilement visible, même sans accolades inutiles. Donc, si vous parvenez à appliquer ces paramètres IDE, je ne vois aucun risque.
Personnellement, je trouve le code qui omet les accolades et les sauts de ligne beaucoup plus lisibles car il évite l'encombrement:
Mais bien sûr, de nombreux développeurs sont très heureux de discuter de telles choses pour toujours et un jour.
la source