Est-ce une mauvaise pratique d'utiliser une instruction if sans accolades?
J'ai vu un code comme celui-ci:
if(statement)
do this;
else
do this;
Je n'aime pas ça, je pense que c'est plus propre et plus lisible
if(statement){
do this;
}else{
do this;
}
Est-ce simplement une question de préférence ou une solution serait-elle préférable à une autre?
Le problème avec la première version est que si vous revenez en arrière et ajoutez une deuxième instruction aux clauses if ou else sans vous rappeler d'ajouter des accolades, votre code se cassera de manière inattendue et amusante.
La facilité de maintenance, c'est toujours plus intelligent d'utiliser le second formulaire.
EDIT: Ned le souligne dans les commentaires, mais je pense qu’il vaut la peine de faire un lien ici. Ce ne sont pas que des conneries hypothétiques de la tour d’ivoire: https://www.imperialviolet.org/2014/02/22/applebug.html
L'abandon des blocs d'instructions est un autre problème: l'ambiguïté else. C’est-à-dire que les langages inspirés du C ignorent l’indentation et n’ont donc aucun moyen de séparer ceci:
if(one)
if(two)
foo();
else
bar();
À partir de ceci:
if(one)
if(two)
foo();
else
bar();
Mon schéma général est que si ça tient sur une ligne, je vais faire:
if(true) do_something();
S'il y a une clause else, ou si le code que je veux exécuter sur true a une longueur significative, maintenez les accolades jusqu'au bout:
if(true) {
do_something_and_pass_arguments_to_it(argument1, argument2, argument3);
}
if(false) {
do_something();
} else {
do_something_else();
}
En fin de compte, cela revient à une question subjective de style et de lisibilité. Cependant, le monde de la programmation générale se divise en deux parties (pour les langages utilisant des accolades): soit les utiliser tout le temps sans exception, soit les utiliser tout le temps avec exception. Je fais partie de ce dernier groupe.
J'utilise le formateur de code du IDE que j'utilise. Cela peut différer, mais cela peut être configuré dans Préférences/Options.
J'aime celui la:
if (statement)
{
// comment to denote in words the case
do this;
// keep this block simple, if more than 10-15 lines needed, I add a function for it
}
else
{
do this;
}
Disposer des accolades dès le premier moment devrait vous éviter de devoir déboguer ceci:
if (statement)
do this;
else
do this;
do that;
La "règle" que je suis est la suivante:
Si l'instruction "if" est en train de tester afin de faire quelque chose (fonctions d'appel I.E., configurer des variables, etc.), utilisez des accolades.
if($test)
{
doSomething();
}
C’est parce que j’ai le sentiment que vous devez préciser quelles fonctions sont appelées et où va le programme, dans quelles conditions. Il est important que le programmeur comprenne exactement quelles fonctions sont appelées et quelles variables sont définies dans cette condition pour les aider à comprendre exactement ce que fait votre programme.
Si l'instruction "if" est en cours de test afin d'arrêter de faire quelque chose (contrôle de flux I.E. dans une boucle ou une fonction), utilisez une seule ligne.
if($test) continue;
if($test) break;
if($test) return;
Dans ce cas, ce qui est important pour le programmeur, c'est de découvrir rapidement quels sont les cas exceptionnels dans lesquels vous ne voulez pas que le code soit exécuté, et tout cela est traité dans $ test, pas dans le bloc d'exécution.
Utilisez des accolades pour toutes les déclarations if, même les plus simples. Ou, réécrivez une simple instruction if pour utiliser l'opérateur ternaire:
if (someFlag) {
someVar= 'someVal1';
} else {
someVar= 'someVal2';
}
Cela ressemble beaucoup plus gentil comme ceci:
someVar= someFlag ? 'someVal1' : 'someVal2';
Mais n'utilisez l'opérateur ternaire que si vous êtes absolument sûr qu'il n'y a rien d'autre à faire dans les blocs if/else!
Je préfère utiliser des accolades. L'ajout d'accolades facilite la lecture et la modification.
Voici quelques liens pour l'utilisation d'accolades:
C'est une question de préférence. Personnellement, j’utilise les deux styles. Si je suis raisonnablement sûr de ne pas avoir besoin d’ajouter d’énoncé, j’utilise le premier style, mais si c’est possible, j’utilise le second. Comme vous ne pouvez plus ajouter d'énoncés au premier style, j'ai entendu certaines personnes recommander de ne pas l'utiliser. Cependant, la deuxième méthode implique une ligne de code supplémentaire et si vous (ou votre projet) utilisez ce type de style de codage, la première méthode est très préférable pour les instructions if simples:
if(statement)
{
do this;
}
else
{
do this;
}
Cependant, je pense que la meilleure solution à ce problème est en Python. Avec la structure de bloc basée sur les espaces, vous ne disposez pas de deux méthodes différentes pour créer une instruction if: vous n'en avez qu'une:
if statement:
do this
else:
do this
Bien que cela pose le "problème" que vous ne pouvez pas utiliser les accolades, vous bénéficiez du fait qu'il ne s'agit plus de lignes que le premier style et qu'il a le pouvoir d'ajouter plus d'instructions.
D'après mon expérience, le seul (très) léger avantage de la première forme est la lisibilité du code, la deuxième forme ajoute du "bruit".
Mais avec les IDE modernes et la génération automatique de code (ou l'auto-complétion), je vous recommande vivement d'utiliser le second formulaire, vous ne perdrez pas de temps à taper des accolades et vous éviterez certains des bogues les plus fréquents.
Il y a suffisamment de bugs qui consomment de l'énergie, les gens ne devraient tout simplement pas ouvrir les portes pour de grandes pertes de temps.
L'une des règles les plus importantes à retenir lors de l'écriture de code est la cohérence. Chaque ligne de code doit être écrite de la même manière, quel que soit son auteur. Être rigoureux empêche les insectes de "se produire";)
C’est la même chose en nommant clairement et explicitement vos variables, méthodes, fichiers ou en les indentant correctement ...
Lorsque mes étudiants acceptent ce fait, ils cessent de se battre contre leur propre code source et commencent à voir le codage comme une activité très intéressante, stimulante et créative. Ils défient leurs esprits, pas leurs nerfs!
J'ai toujours essayé de rendre mon code standard et d'avoir le même aspect que possible. Cela facilite la lecture par les autres utilisateurs lorsqu'ils sont chargés de le mettre à jour. Si vous faites votre premier exemple et ajoutez une ligne au milieu, cela échouera.
Ne fonctionnera pas:
si (déclaration) faites ceci; et ça; sinon faire ceci;
Personnellement, je n'utilise que le premier style qui ne lève qu'une exception ou retourne prématurément d'une méthode. Comme l'argument Vérification au début d'une fonction, car dans ces cas, j'ai rarement plus d'une chose à faire et il n'y a jamais d'autre chose.
Exemple:
if (argument == null)
throw new ArgumentNullException("argument");
if (argument < 0)
return false;
Sinon j'utilise le second style.
Ma préférence personnelle utilise un mélange d'espaces et de crochets comme ceci:
if( statement ) {
// let's do this
} else {
// well that sucks
}
Je pense que cela semble propre et rend mon code très facile à lire et le plus important - débogage.
Je suis d'accord avec la plupart des réponses sur le fait qu'il vaut mieux être explicite dans votre code et utiliser des accolades. Personnellement, j’adopterais un ensemble de normes de codage et veillerais à ce que tous les membres de l’équipe les connaissent et se conforment. Là où je travaille, nous utilisons les normes de codage publiées par IDesign.net pour les projets .NET.
Je préfère mettre une accolade. Mais parfois, l'opérateur ternaire aide.
Au lieu de :
int x = 0;
if (condition) {
x = 30;
} else {
x = 10;
}
Il faut simplement faire: int x = condition ? 30 : 20;
Imaginez aussi un cas:
if (condition)
x = 30;
else if (condition1)
x = 10;
else if (condition2)
x = 20;
Ce serait beaucoup mieux si vous mettez l'accolade bouclée po.