Pour la plupart, il s'agit d'une préférence personnelle, mais il y a certaines choses à considérer.
Bugs possibles
Bien que l' on peut soutenir que les bugs causés par l' oubli d'accolades add-in sont rares, de ce que j'ai vu que ils ne se produisent de temps en temps (ne pas oublier le fameux goto IOS échec bug). Donc, je pense que cela devrait être un facteur lors de l'examen de votre style de code (certains outils vous avertissent de l' indentation trompeuse , donc cela dépend aussi de votre chaîne d'outils) .
Code valide (qui se lit comme si cela pouvait être un bogue)
Même en supposant que votre projet ne souffre pas de tels bogues, lors de la lecture du code, vous pouvez voir des blocs de code qui pourraient ressembler à des bogues - mais ne le sont pas, prenant en compte certains de vos cycles mentaux.
Nous commençons par:
if (foo)
bar();
Un développeur ajoute un commentaire utile.
if (foo)
// At this point we know foo is valid.
bar();
Plus tard, un développeur l'étend.
if (foo)
// At this point we know foo is valid.
// This never fails but is too slow even for debug, so keep disabled.
// assert(is_valid(foo));
bar();
Ou ajoute un bloc imbriqué:
if (foo)
while (i--) {
bar(i);
baz(i);
}
Ou utilise une macro:
if (foo)
SOME_MACRO();
"... Étant donné que les macros peuvent définir plusieurs lignes de code, la macro utilise- do {...} while (0)t-elle plusieurs lignes? Ce devrait être parce que c'est dans notre guide de style, mais je ferais mieux de vérifier au cas où!!"
Les exemples ci-dessus sont tous du code valide. Cependant, plus le contenu du bloc de code est important, plus vous devez lire pour vous assurer qu'il n'y a pas d'erreur.
Peut-être que votre style de code définit que les blocs multilignes nécessitent une accolade (peu importe le type, même s'ils ne sont pas du code) , mais j'ai déjà vu ce genre de commentaires être ajoutés au code de production. Lorsque vous le lisez, il y a un petit doute sur le fait que celui qui a modifié ces lignes en dernier ait oublié d'ajouter une accolade. Parfois, je ressens le besoin de vérifier si tout se passe bien (surtout lorsque vous recherchez un bogue dans cette partie du code) .
Diff bruit
Une raison pratique d'utiliser des accolades pour des lignes simples est la réduction du bruit diff .
C'est-à-dire changer:
if (foo)
bar();
À:
if (foo) {
bar();
baz();
}
... provoque l'affichage de la ligne conditionnelle dans un diff comme étant modifiée, ce qui ajoute une surcharge légère mais inutile.
- les lignes apparaissent comme étant modifiées dans les révisions de code, si vos différents outils sont basés sur des mots, vous pouvez facilement voir que seul l'accolade a été modifiée, mais cela prend plus de temps à vérifier que si la ligne n'a pas changé du tout.
Cela dit, tous les outils ne prennent pas en charge la différenciation basée sur les mots: diff (svn, git, hg, etc.) montrera que si la ligne entière était modifiée, même avec des outils sophistiqués, vous devrez parfois parcourir rapidement une ligne simple. basé sur diff pour voir ce qui a changé.
- Les outils d'annotation (tels que
git blame) indiquent que la ligne a été modifiée, ce qui rend le suivi de l'origine d'une ligne plus complexe pour trouver le changement réel .
Celles-ci sont toutes deux petites et dépendent du temps que vous consacrez à la révision du code ou au suivi du code pour valider les lignes de code modifiées.
Un inconvénient plus tangible d'avoir des lignes supplémentaires change dans un diff, leur plus grande probabilité que des modifications dans le code provoquent des conflits qui se fusionnent et qui doivent être résolus manuellement .
Il y a une exception à cela, pour les bases de code qui ont {sur leur propre ligne - ce n'est pas un problème.
L' argument de bruit diff ne tient pas si vous écrivez dans ce style:
if (foo)
{
bar();
baz();
}
Cependant, ce n'est pas une convention si commune, donc il faut principalement ajouter la réponse pour la complétude (ne suggérant pas aux projets d'utiliser ce style) .
