Puis-je supprimer les accolades en Java?
J'ai cherché cela, mais je n'ai pas pu trouver de réponse et pour une raison quelconque, j'avais trop honte de demander au professeur, à cause de ce sentiment quand des centaines de personnes vous regardaient ...
Quoi qu'il en soit, ma question est quelle est l'importance d'avoir des crochets? Est-ce que je peux les omettre? Exemple:
for (int i = 0; i < size; i++) {
a += b;
}
contre
for (int i = 0; i < size; i++)
a += b;
Je sais que les deux fonctionneront, mais si j'oublie les crochets (ce que j'ai tendance à faire beaucoup, en raison de la visibilité), cela changera-t-il quelque chose? Comme je l'ai dit, je sais que cela fonctionne, je l'ai testé une douzaine de fois, mais maintenant certaines de mes affectations universitaires sont de plus en plus grandes et, pour une raison quelconque, j'ai une peur irrationnelle de ce que, à long terme, cela puisse causer des problèmes? Y a-t-il une raison de craindre cela?
Cela ne changera rien du tout à part la maintenabilité de votre code. J'ai vu un code comme celui-ci:
for (int i = 0; i < size; i++)
a += b;
System.out.println("foo");
ce qui signifie ceci:
for (int i = 0; i < size; i++)
a += b;
System.out.println("foo");
... mais qui devrait aurait été ceci:
for (int i = 0; i < size; i++) {
a += b;
System.out.println("foo");
}
Personnellement, je toujours inclure les crochets pour réduire les risques de confusion lors de la lecture ou de la modification du code.
Les conventions de codage de chaque entreprise pour laquelle j'ai travaillé en ont fait la demande - ce qui ne veut pas dire que certaines autres entreprises n'ont pas de conventions différentes ...
Et juste au cas où vous penseriez que cela ne ferait jamais une différence: je devais résoudre un bogue une fois qui était à peu près équivalent au code ci-dessus. C'était remarquablement difficile à repérer… (certes, c'était il y a des années, avant que je ne commence à faire des tests unitaires, ce qui aurait sans aucun doute rendu le diagnostic plus facile).
L'utilisation d'accolades rend le code plus facile à gérer et à comprendre. Donc, vous devriez les considérer par défaut.
Je saute parfois des accolades sur clauses de garde pour rendre le code plus compact. Mon exigence est que ce sont des instructions if qui sont suivies d'une instruction jump, telle que return ou throw. Aussi, je les garde dans la même ligne pour attirer l'attention sur l'idiome, par exemple:.
if (!isActive()) return;
Ils s'appliquent également au code à l'intérieur des boucles:
for (...) {
if (shouldSkip()) continue;
...
}
Et à d'autres conditions de saut de méthodes qui ne sont pas nécessairement au sommet du corps de la méthode.
Certaines langues (comme Perl ou Ruby) ont une sorte d'instruction conditionnelle, où les accolades ne s'appliquent pas:
return if (!isActive());
// or, more interestingly
return unless (isActive());
Je considère que c'est équivalent à ce que je viens de décrire, mais explicitement supporté par le langage.
Il n'y a pas de différence. Le principal problème de la deuxième version est que vous pourriez écrire ceci:
for (...)
do_something();
do_something_else();
lorsque vous mettez à jour cette méthode, pensez que do_something_else() est appelé à l'intérieur de la boucle. (Et cela conduit à des sessions de débogage éreintantes.)
Il existe un deuxième problème que la version avec accolade n’a pas, et il est peut-être encore plus difficile à déceler:
for (int i=0; i<3; i++);
System.out.println("Why on earth does this print just once?");
Alors gardez les accolades à moins d’avoir une bonne raison, c’est juste quelques touches de plus.
Dans la plupart des cas, les réponses mentionnées jusqu’à présent sont correctes. Mais il y a des inconvénients à cela du point de vue de la sécurité des choses. Ayant travaillé dans une équipe de paiement, la sécurité est un facteur beaucoup plus important qui motive de telles décisions. Disons que vous avez le code suivant:
if( "Prod".equals(stage) )
callBankFunction ( creditCardInput )
else
callMockBankFunction ( creditCardInput )
Maintenant, disons que ce code ne fonctionne pas à cause d'un problème interne. Vous voulez vérifier l'entrée. Donc, vous apportez le changement suivant:
if( "Prod".equals(stage) )
callBankFunction ( creditCardInput )
else
callMockBankFunction ( creditCardInput )
Logger.log( creditCardInput )
Supposons que vous résolvez le problème et déployez ce code (et peut-être que le relecteur et vous pensez que cela ne posera pas de problème, car il ne fait pas partie de la condition 'Prod'). Comme par magie, vos journaux de production impriment maintenant les informations de carte de crédit du client qui sont visibles pour tout le personnel pouvant voir les journaux. Dieu nous en préserve si l'un d'entre eux (avec une intention malveillante) s'empare de ces données.
Ainsi, ne pas donner de doublure et un peu de codage négligent peuvent souvent conduire à une violation des informations sécurisées. Il est également classé comme vulnérabilité en Java par CERT - Software Engineering Institure, CMU .
Si vous avez une seule instruction, vous pouvez omettre les crochets. Pour plusieurs instructions, il est nécessaire de placer des crochets pour déclarer un bloc de code.
Lorsque vous utilisez des crochets, vous déclarez un bloc de code:
{
//Block of code
}
Les crochets doivent également être utilisés avec une seule instruction lorsque vous vous trouvez dans une situation d’instruction imbriquée afin d’améliorer la lisibilité. Par exemple:
for( ; ; )
if(a == b)
doSomething()
il est plus lisible écrit avec des crochets aussi si pas nécessaire:
for( ; ; ) {
if(a == b) {
doSomething()
}
}
Si vous utilisez des crochets, votre code est plus lisible ... Et si vous devez ajouter un opérateur dans le même bloc, vous pouvez éviter les erreurs
Je pense que perdre des accolades est une bonne chose, si vous utilisez également le formatage automatique, car votre indentation est toujours correcte, il sera donc facile de repérer les erreurs de cette façon.
Dire qu'abandonner les accolades est mauvais, bizarre ou illisible, c'est faux, car le langage tout entier est basé sur cette idée, et il est très populaire (python).
Mais je dois dire que sans l'aide d'un formateur, cela peut être dangereux.
L'utilisation des parenthèses protège le code des modifications ultérieures. J'ai vu des cas où des crochets ont été omis et quelqu'un a ajouté plus tard du code et ne les a pas placés à ce moment-là. En conséquence, le code qu'ils ont ajouté n'est pas entré dans la section qu'ils pensaient avoir. Donc, je pense que la réponse est que sa bonne pratique à la lumière des modifications futures du code. J'ai vu des groupes de logiciels adopter cela comme norme, c'est-à-dire nécessitant toujours des crochets même avec des blocs à une ligne pour cette raison.
Plus de soutien de ma part pour le groupe "toujours accolades". Si vous omettez les accolades pour les boucles/branches à instruction unique, placez l'instruction sur la même ligne que l'instruction de contrôle,
if (condition) doSomething();
for(int i = 0; i < arr.length; ++i) arr[i] += b;
de cette façon, il est plus difficile d’oublier l’insertion d’accolades lorsque le corps est dilaté. Toujours, utilisez des curlies quand même.
Si vous avez une seule déclaration dans la boucle, elle est la même.
Par exemple, voir le code suivant:
for(int i=0;i<4;i++)
System.out.println("shiva");
nous avons une seule déclaration dans le code ci-dessus. donc pas de problème
for(int i=0;i<4;i++)
System.out.println("shiva");
System.out.println("End");
Nous avons ici deux déclarations, mais seule la première déclaration entre dans la boucle, mais pas la deuxième.
Si vous avez plusieurs instructions sous une seule boucle, vous devez utiliser des accolades.
Si vous supprimez des accolades, il ne lira que la première ligne d’instruction. Toute ligne supplémentaire ne sera pas lue. Si vous avez plus d'une ligne d'instruction à exécuter, utilisez des accolades, sinon une exception sera levée.
Résultat, c'est la même chose.
Seulement deux choses à considérer.
- Maintenabilité du code
- Code faiblement couplé. (peut exécuter autre chose, car vous n'avez pas spécifié l'étendue de la boucle.)
Note: Dans mon observation, s'il s'agit d'une boucle avec une boucle. La boucle intérieure sans accolades est également sûre. Le résultat ne variera pas.
De nos jours, il est très facile de réindenter des codes pour savoir quel bloc de codes contient if ou for/while. Si vous insistez sur le fait qu'il est difficile de refaire le retrait, les crochets placés au mauvais retrait peuvent également vous gêner.
for(int i = 0; i < 100; i++) { if(i < 10) {
doSomething();
} else { for(int j = 0; j < 5; j++) {
doSomethingElse();
}
}}
Si vous faites cela partout, votre cerveau va se décomposer en un rien de temps. Même avec des crochets, vous dépendez de l'indentation pour rechercher visuellement le début et la fin des blocs de code.
Si l'indentation est importante, vous devez déjà écrire votre code correctement, de sorte que les autres personnes n'ont pas besoin de réindenter vos codes pour les lire correctement.
Si vous voulez dire que l'exemple précédent est trop faux/délibéré et que les crochets sont là pour capturer le problème d'indentation imprudent (en particulier lorsque vous copiez/collez des codes), alors considérez ceci:
for(int i = 0; i < 100; i++) {
if(i < 10) {
doSomething();
}
else {
for(int j = 0; j < 5; j++) {
doSomethingElse();
}
}
Oui, cela semble moins grave que l'exemple précédent, mais vous pouvez toujours être dérouté par une telle indentation.
À mon humble avis, il incombe à la personne qui rédige le code de vérifier le code et de s’assurer que les éléments sont correctement mis en retrait avant de procéder à d’autres tâches.
Il est probablement préférable d'utiliser les accolades un peu partout pour le simple fait que le débogage serait une nuisance extrême. Mais sinon, une ligne de code ne nécessite pas nécessairement le support. J'espère que cela t'aides!
utiliser des accolades redondantes pour prétendre que le code est plus facile à gérer soulève la question suivante: si les personnes qui écrivent, se posent des questions sur le code et le maintiennent plus avant ont des problèmes comme ceux décrits précédemment (liés à l'indentation ou à la lisibilité), ils ne devraient peut-être pas du tout programmer. .
ce devrait être un réflexe de reformater le code aussi ... bien sûr pour les programmeurs professionnels dans les équipes professionnelles