Pourquoi est-il considéré comme une mauvaise pratique d'omettre les accolades?
Pourquoi tout le monde me dit que l'écriture de code comme ceci est une mauvaise pratique?
if (foo)
Bar();
//or
for(int i = 0 i < count; i++)
Bar(i);
Mon principal argument en faveur de l’omission des accolades est qu’il peut parfois contenir deux fois plus de lignes. Par exemple, voici du code pour Peindre un effet de rayonnement pour une étiquette en C #.
using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
{
for (int x = 0; x <= GlowAmount; x++)
{
for (int y = 0; y <= GlowAmount; y++)
{
g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));
}
}
}
//versus
using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
for (int x = 0; x <= GlowAmount; x++)
for (int y = 0; y <= GlowAmount; y++)
g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));
Vous pouvez également obtenir l’avantage supplémentaire d’enchaîner usings sans avoir à indenter un million de fois.
using (Graphics g = Graphics.FromImage(bmp))
{
using (Brush brush = new SolidBrush(backgroundColor))
{
using (Pen pen = new Pen(Color.FromArgb(penColor)))
{
//do lots of work
}
}
}
//versus
using (Graphics g = Graphics.FromImage(bmp))
using (Brush brush = new SolidBrush(backgroundColor))
using (Pen pen = new Pen(Color.FromArgb(penColor)))
{
//do lots of work
}
L'argument le plus courant pour les accolades concerne la programmation de maintenance et les problèmes qui en résulteraient en insérant du code entre l'instruction if originale et le résultat souhaité:
if (foo)
Bar();
Biz();
Des questions:
- Est-il faux de vouloir utiliser la syntaxe plus compacte proposée par le langage? Les personnes qui conçoivent ces langues sont intelligentes, je ne peux pas imaginer qu'elles mettraient une fonctionnalité toujours mauvaise à utiliser.
- Devrions-nous ou devrions-nous pas écrire du code pour que le plus petit dénominateur commun puisse comprendre et n’avoir aucun problème à l’utiliser?
- Y a-t-il un autre argument qui me manque?
En fait, la seule fois où je me suis vraiment moqué, c'est quand je déboguais et commentais bar ():
if(foo)
// bar();
doSomethingElse();
Autre que cela, j'ai tendance à utiliser:
if(foo) bar();
Ce qui prend en charge le cas ci-dessus.
EDIT Merci d'avoir clarifié la question, je suis d'accord, nous ne devrions pas écrire de code au plus petit dénominateur commun.
Vitesse de lecture ...
Mis à part ce qui a déjà été mentionné. À ce stade, je suis déjà préparé à analyser les instructions comportant des accolades et des espaces. Alors j'ai lu:
if (condition)
{
DoSomething();
}
DoSomethingElse();
Légèrement plus rapide que ce que je lisais:
if (condition) DoSomething();
DoSomethingElse();
Je le lis un peu plus lentement s'il ressemble à ceci:
if (condition) DoSomething();
DoSomethingElse();
Je lis ceci beaucoup plus lentement que le précédent:
if (condition)
DoSomething();
DoSomethingElse();
beause Je ne peux pas m'empêcher de le relire au cas par cas et je me demande si l'auteur avait l'intention:
if (condition)
{
DoSomething();
DoSomethingElse();
}
Déjà couvert en général, mais quand il s’agit de lecture ci-dessous, je vais regarder cela assez longtemps pour vérifier ce que l’auteur voulait faire. Je peux même traquer l'auteur original pour le confirmer.
if (condition)
DoSomething();
DoSomethingElse();
Si c'est quelque chose de petit, écrivez-le comme ceci:
if(foo()) bar();Si le temps est suffisant pour séparer deux lignes, utilisez des accolades.
J'avais aussi l'habitude de penser qu'il était préférable de n'utiliser que des appareils dentaires lorsque c'est vraiment nécessaire. Mais plus maintenant, la raison principale, lorsque vous avez beaucoup de code, cela le rend plus lisible et vous pouvez analyser le code plus rapidement lorsque vous avez un style de contreventement cohérent.
Une autre bonne raison de toujours utiliser des accolades, à part quelqu'un qui ajoute une deuxième déclaration à if, est quelque chose comme ceci pourrait se produire:
if(a)
if(b)
c();
else
d();
Avez-vous remarqué que la clause else est en réalité celle de "if (b)"? Vous l'avez probablement fait, mais feriez-vous confiance à quiconque pour se familiariser avec ce piège?
Donc, si juste pour la cohérence et parce que vous ne savez jamais quelles choses inattendues pourraient se produire lorsque quelqu'un d'autre (ce sont toujours les autres qui sont stupides), le code est modifié, je mets toujours des accolades, car cela rend le code source plus lisible, plus rapide à analyser par votre cerveau. Ce n'est que pour les déclarations les plus simples, comme dans le cas d'une délégation ou d'un commutateur, où vous savez que la clause ne sera jamais prolongée, que je laisserais de côté.
Les lignes sont bon marché. La puissance du processeur est bon marché. Le temps de développement est très coûteux.
En règle générale, si je ne développais pas une application absolument critique en termes de ressources et de vitesse, je pècherais toujours du côté de l'écriture de code
(a) Facile pour tout autre développeur de suivre ce que je fais
(b) Commentez des parties spécifiques du code qui peuvent en avoir besoin
(c) Facile à déboguer en cas de problème
(d) Facile à modifier si cela doit être à l'avenir (c'est-à-dire ajouter/supprimer du code)
La rapidité ou l'élégance académique du code est secondaire à ces facteurs du point de vue des entreprises. Cela ne veut pas dire que je me suis mis à écrire du code maladroit ou laid, mais c'est mon ordre de priorité.
En omettant les accolades dans la plupart des cas, il est pour moi plus difficile de résoudre les problèmes (b), (c) et (d) (remarque cependant pas impossible). Je dirais que l'utilisation d'accolades ou non n'a pas d'effet sur (a).
Je préfère la clarté qu'offre l'accolade. Vous savez exactement ce que cela veut dire et vous n'avez pas à deviner si quelqu'un a juste gaffé et l'a laissé (et a introduit un bogue). La seule fois où je les omets, c'est quand je mets le if et l'action sur la même ligne. Je ne le fais pas très souvent non plus. En fait, je préfère les espaces introduits en plaçant l’accolade sur sa propre ligne, bien qu’après des années de programmation K & R similaire à C, terminer la ligne avec une accolade est une pratique que je dois travailler à surmonter si le IDE ne l'applique pas pour moi.
if (condition) action(); // ok by me
if (condition) // normal/standard for me
{
action();
}
Ce n'est pas toujours considéré comme une mauvaise pratique. Le Directives de codage de projet mono suggère de ne pas utiliser d'accolades si cela n'est pas nécessaire. La même chose pour le GNU Coding Standards . Je pense que c'est une question de goût personnel, comme toujours avec les normes de codage.
Je pense que c'est une question de directives pour le projet sur lequel vous travaillez et de goût personnel.
Je les omets habituellement lorsqu'ils ne sont pas nécessaires, à l'exception de certains cas tels que:
if (something)
just one statement; // i find this ugly
else
{
// many
// lines
// of code
}
je préfère
if (something)
{
just one statement; // looks better:)
}
else
{
// many
// lines
// of code
}
J'avais l'habitude de penser de la même manière.
Jusqu'au jour où (pourquoi y a-t-il toujours ce "jour" qui change votre vie pour toujours?), Nous passons de 24 à 36 heures d'affilée sans code de production pour le débogage du sommeil, mais nous découvrons que quelqu'un n'a pas mis d'accolades associé à un changement de recherche/remplacement. .
C'était quelque chose comme ça.
if( debugEnabled )
println( "About to save 1 day of work to some very important place.");
saveDayData();
Ce qui est venu après était
if( debugEnabled )
// println( "About to save 1 day of work to some very important place.");
saveDayData();
Il s’avère que le système génère 500 Mo de journaux par jour et on nous a demandé de l’arrêter. Le drapeau de débogage ne suffisait pas, donc une recherche et remplacement de println était en ordre.
Néanmoins, lorsque l'application est entrée en production, l'indicateur de débogage était désactivé et l'important "saveDayData" n'a jamais été appelé.
EDIT
Maintenant, le seul endroit où je n'utilise pas les accolades est la construction if/try.
if( object != null ) try {
object.close();
} catch( .....
Après avoir regardé un développeur superstar faire cela.
L'un des cas où cela peut vous mordre est de retour dans l'ancien temps des macros C/C++. Je sais qu’il s’agit d’une question C #, mais les normes de codage sont souvent reportées sans les raisons pour lesquelles la norme a été créée.
Si vous ne faites pas très attention lorsque vous créez vos macros, vous risquez de poser des problèmes avec les instructions if qui n'utilisent pas le {}.
#define BADLY_MADE_MACRO(x) function1(x); function2(x);
if (myCondition) BADLY_MADE_MACRO(myValue)
Maintenant, ne vous méprenez pas, je ne dis pas que vous devriez toujours faire {} simplement pour éviter ce problème en C/C++, mais j'ai dû faire face à des bugs très étranges à cause de cela.
Je suis assez content de:
foreach (Foo f in foos)
foreach (Bar b in bars)
if (f.Equals(b))
return true;
return false;
Personnellement, je ne vois pas pourquoi
foreach (Foo f in foos)
{
foreach (Bar b in bars)
{
if (f.Equals(b))
{
return true;
}
}
}
return false;
est plus lisible.
Oui, les lignes sont gratuites, mais pourquoi devrais-je devoir faire défiler des pages et des pages de code alors que leur taille pourrait être réduite de moitié?
S'il y a une différence de lisibilité ou de maintenabilité, alors bien sûr, mettez des accolades ... mais dans ce cas, je ne vois aucune raison de le faire.
Aussi, je vais toujours mettre des accolades pour imbriqué si c'est là où j'ai imbriqué d'autre
if (condition1)
if (condition2)
doSomething();
else (condition2)
doSomethingElse();
contre
if (condition1)
if (condition2)
doSomething();
else (condition2)
doSomethingElse();
est terriblement déroutant, alors je l’écris toujours ainsi:
if (condition1)
{
if (condition2)
doSomething();
else (condition2)
doSomethingElse();
}
J'utilise autant que possible des opérateurs ternaires, mais je jamais les imbriquer .
Pour être franc je le vois comme:
Les bons programmeurs défendent la programmation, les mauvais programmeurs non.
Puisqu'il y a plusieurs exemples ci-dessus et mes propres expériences similaires avec des bugs liés à l'oubli des orthèses, j'ai appris la voie difficile pour TOUJOURS METTRE DES BRACES.
Toute autre solution consiste à choisir un style personnel plutôt que la sécurité, ce qui est clairement une mauvaise programmation.
Joel mentionne même cela dans Faire en sorte que le code soit faux
Une fois que vous avez été mordu par un bogue à cause des accolades manquantes, vous apprendrez que les accolades manquantes semblent fausses car vous savez que c'est un emplacement potentiel pour qu'un autre bogue se produise.
Je suis impressionné et humilié de constater que mes pairs dans ce domaine de la programmation informatique (vous êtes nombreux) ne sont pas découragés par la possibilité de bugs potentiels lorsque vous sautez les accolades sur des blocs d'une seule ligne.
Je suppose que cela signifie que je ne suis pas intelligent. J'ai commis des erreurs à ce sujet plusieurs fois. J'ai corrigé les erreurs des autres autour de cela. À cause de cela, j'ai observé des logiciels livrés avec des bogues (RDP sur une machine fonctionnant sous VS2002 et la police de votre fenêtre de surveillance devenant imprévisible).
Si je regarde toutes les erreurs que j'ai faites qui auraient pu être évitées avec un changement de style de codage, la liste est très longue. Si je n'avais pas changé d'approche dans chacun de ces cas, je ne l'aurais probablement jamais fait en tant que programmeur. Encore une fois, je suppose que je ne suis pas intelligent. Pour compenser, je suis un fervent utilisateur d'accolades sur des blocs d'une seule ligne depuis longtemps.
Cela dit, certaines choses ont changé dans le monde qui rendent la règle de "tu utiliseras des accolades sur des blocs à une ligne" moins pertinente aujourd'hui que lorsque Moïse nous l'avait présentée:
Certains langages populaires font disparaître le problème en obligeant l'ordinateur à lire l'indentation, tout comme le programmeur le fait (par exemple, Python).
Mon éditeur met automatiquement en forme pour moi, donc les chances de me tromper par indentation sont très réduites.
TDD signifie que si j'introduis un bogue parce que je suis dérouté par un bloc d'une seule ligne, je suis beaucoup plus susceptible de le découvrir rapidement.
Refactoring et expressivité du langage signifie que mes blocs sont beaucoup plus courts et que les blocs d’une seule ligne se produisent beaucoup plus souvent que d’habitude. Hypothétiquement, avec une application impitoyable d'ExtractMethod, je pourrais éventuellement avoir seulement des blocs monolignes dans tout mon programme. (Je me demande à quoi ça ressemblerait?)
En fait, le refactoring impitoyable et l’omission d’accolades sur des blocs à une ligne peuvent présenter un avantage distinct: lorsque vous voyez des accolades, une petite alarme peut retentir dans votre tête indiquant "complexité ici! Attention!". Imaginez si c'était la norme:
if (condition) Foo(); // normal, everyday code
if (condition)
{
// something non-trivial hapening; pay attention!
Foo();
Bar();
}
Je me lance dans l'idée de changer ma convention de codage en quelque chose comme "les blocs d'une seule ligne peuvent ne jamais avoir d'accolades" ou "si vous pouvez placer le bloc sur la même ligne que la condition, et que tout cela ne dépasse pas 80 caractères, omettre les accolades ". Nous verrons.
Il y a toujours des exceptions, mais je dirais qu'il ne faut pas omettre les accolades uniquement si elles se présentent sous l'une des formes suivantes:
if(x == y) for(/* loop */) { //200 lines } //rampion's example: for(/* loop */) { for(/* loop */) for(/* loop */) { //several lines } }
Sinon, cela ne me pose aucun problème.
J'utilise parfois le code le plus bas (plusieurs instructions utilisant), mais à part cela, je mets toujours les accolades. Je trouve que cela rend le code plus clair. Il est manifestement évident, au-delà de l'indentation, qu'une déclaration fait partie d'un bloc (et donc probablement d'un if, etc.).
J'ai vu le
if (...)
foo();
bar();
bug me mord (ou plutôt "moi et mes collègues" - je n'ai pas introduit le bug) ne fois. C'était en dépit du fait que nos normes de codage à l'époque recommandaient d'utiliser des accolades partout. Cela m'a pris un temps étonnamment long à repérer - parce que vous voyez ce que vous voulez voir. (C'était il y a environ 10 ans. Peut-être que je trouverais ça plus vite maintenant.)
Bien sûr, si vous utilisez "accolade à la fin de la ligne", cela réduira les lignes supplémentaires, mais personnellement, je n'aime pas ce style. (Je l'utilise au travail et je l'ai trouvé moins désagréable que prévu, mais c'est quand même un peu désagréable.)
Je conviens que "si vous êtes assez intelligent pour que quelqu'un vous paye pour écrire du code, vous devriez être assez intelligent pour ne pas compter uniquement sur l'indentation pour voir le flux du code".
Cependant ... des erreurs peuvent être commises, et celle-ci est difficile à déboguer ... surtout si vous consultez le code de quelqu'un d'autre.
Ma philosophie est que si cela rend le code plus lisible, pourquoi ne pas le faire?
Évidemment, vous devez tracer la ligne de démarcation quelque part, comme pour trouver ce juste milieu entre des noms de variables concis et trop descriptifs. Mais les crochets évitent vraiment les erreurs et améliorent la lisibilité du code.
Vous pouvez affirmer que les personnes assez intelligentes pour devenir des codeurs le seront suffisamment pour éviter les bogues qui bloquent les déclarations sans parenthèse. Mais pouvez-vous honnêtement dire que vous n’avez jamais été dérangé par quelque chose d'aussi simple qu'une faute d'orthographe? Une telle Minutia peut être écrasante quand on regarde de gros projets.
Parmi les trois conventions:
if(addCurleyBraces()) bugFreeSofware.hooray();
et:
if(addCurleyBraces())
bugFreeSofware.hooray();
et (qui représentent n'importe quel style d'indentation utilisant une accolade ouvrante et fermante):
if(addCurleyBraces()) {
bugFreeSofware.hooray();
}
Je préfère le dernier comme:
- Je trouve plus facile à lire si toutes les déclarations if sont écrites de manière uniforme.
- Cela peut rendre le logiciel un peu plus robuste et sans bug. Cependant, tous les éditeurs modernes et les éditeurs de texte avancés possèdent des fonctionnalités d'indentation automatique agréables que tout le monde devrait utiliser tant que cela ne perturbe pas le formatage des commentaires ou ne respecte pas les normes de l'équipe (dans de nombreux cas, il est possible de créer un schéma de formatage personnalisé. et le partager avec l'équipe). Mon point ici est que si l’indentation est faite correctement, le risque d’introduction de bogue est un peu réduit.
- Je préfère que l'expression booléenne et les déclarations à exécuter soient sur des lignes différentes. J'aime pouvoir marquer une ligne à des fins de débogage. Même si j'utilise un IDE où je peux marquer une déclaration et y aller d'une étape à l'autre, c'est une opération interactive et je pourrais oublier où j'ai commencé à déboguer ou au moins cela me prendra un peu peu plus de temps pour parcourir le code plusieurs fois (car je dois marquer la position manuellement à chaque fois pendant le débogage).
Je suis un fervent partisan de la rédaction d'un code ordonné et concis, mais j'utiliserais toujours des accolades. Je trouve qu'ils constituent un moyen pratique de voir rapidement la portée dans laquelle une ligne de code particulière existe. Il n'y a pas d'ambiguïté, c'est juste explicitement exposé devant vous.
Certains diront que c'est un cas de préférence, mais je trouve le flux logique d'un programme beaucoup plus facile à suivre s'il est cohérent en interne, et je ne pense pas qu'il soit cohérent d'écrire une instruction IF comme celle-ci;
if(x < y)
x = y;
else
y = x;
Et un autre comme ça;
if(x < y)
{
x = y;
x++;
}
else
{
y = x;
y++;
}
Je préfère choisir un style général et m'en tenir à ça :)
Vos principaux arguments contre l'utilisation des accolades sont qu'ils utilisent des lignes supplémentaires et qu'ils nécessitent un retrait supplémentaire.
Les lignes sont (presque) gratuites, minimiser le nombre de lignes dans votre code ne devrait pas être un objectif.
Et l'indentation est indépendante de l'utilisation de l'accolade. Dans votre exemple d'utilisation de cascade, je pense toujours que vous devriez les indenter même lorsque vous omettez les accolades.
D'accord, c'est une vieille question à laquelle on a répondu à mort. J'ai quelque chose à ajouter.
Tout d'abord, je dois juste dire UTILISER LES BRACES. Ils ne peuvent qu’aider à la lisibilité, et celle-ci (pour vous-même et pour les autres!) Devrait figurer en bonne place sur votre liste de priorités, sauf si vous écrivez Assembly. Un code illisible entraîne toujours des bogues. Si vous constatez que les accolades font que votre code prend trop de place, vos méthodes sont probablement trop longues. La plupart ou toutes les méthodes doivent correspondre à une hauteur d'écran si vous le faites bien, et Trouver (F3) est votre ami.
Maintenant pour mon ajout: Il y a un problème avec ceci:
if (foo) bar();
Essayez de définir un point d'arrêt qui ne sera atteint que si bar () est exécuté. Vous pouvez le faire en C # en plaçant le curseur sur la seconde moitié du code, mais ce n'est pas évident et c'est un peu pénible. En C++, vous ne pouvez pas le faire du tout. Un de nos développeurs les plus expérimentés travaillant sur le code C++ insiste pour que les instructions 'if' soient divisées en deux lignes pour cette raison. Et je suis d'accord avec lui.
Alors faites ceci:
if (foo)
{
bar(); //It is easy to put a breakpoint here, and that is useful.
}
L’un des principaux problèmes réside dans le fait que vous avez des régions composées de lignes simples et non linéaires, ainsi que la séparation de l’état de contrôle (for, if, qu’avez-vous) et la fin de la déclaration.
Par exemple:
for (...)
{
for (...)
for (...)
{
// a couple pages of code
}
// which for block is ending here? A good text editor will tell you,
// but it's not obvious when you're reading the code
}
J'étais un grand partisan de "l'accolade est un MUST!", Mais depuis que j'ai adopté les tests unitaires, je constate que mes tests unitaires protègent les déclarations sans bracelet des scénarios suivants:
if (foo)
snafu();
bar();
Avec de bons tests unitaires, je peux en toute confiance omettre les accolades pour les déclarations simples afin d'améliorer la lisibilité (oui, cela peut être subjectif).
Alternativement, pour quelque chose comme ce qui précède, je voudrais probablement en ligne à ressembler à:
if (foo) snafu();
De cette façon, le développeur qui doit ajouter bar () à la condition serait plus apte à reconnaître le manque d'accolades et à les ajouter.
Utilisez un jugement personnel.
if (foo)
bar();
est bien par lui-même. À moins que vous ne craigniez que des abrutis ne mettent quelque chose comme ça plus tard:
if (foo)
bar();
baz();
Si vous n'êtes pas inquiet pour les abrutis, tout va bien (je ne le suis pas - s'ils ne peuvent pas comprendre correctement la syntaxe du code de base, c'est le moindre de leurs problèmes)>
En échange, c'est beaucoup plus lisible.
Le reste du temps:
if (foo) {
bar();
baz();
}
Ce qui a été mon préféré aussi longtemps que je me souvienne. Aditionellement:
if (foo) {
bar();
baz();
} else {
qux();
}
Travaille pour moi.
L'espace vertical en soi n'est pas très pertinent, pas la lisibilité. L'accolade ouvrante sur une ligne par elle-même arrête simplement la conversation pour un élément syntaxique, jusqu'à ce que votre œil passe à la ligne suivante. Pas ce que j'aime.
Disons que vous avez du code:
if (foo)
bar();
et puis quelqu'un d'autre arrive et ajoute:
if (foo)
snafu();
bar();
Selon la façon dont c'est écrit, bar (); est maintenant exécuté sans condition. En incluant les accolades, vous évitez ce genre d'erreur accidentelle. Le code doit être écrit de manière à rendre de telles erreurs difficiles ou impossibles à commettre. Si je passais en revue le code et voyais les accolades manquantes, en particulier réparties sur plusieurs lignes, je créerais un défaut. Dans les cas où cela est justifié, conservez-le sur une seule ligne afin de minimiser les risques de commettre une telle erreur.
Réduire les lignes n'est pas vraiment un bon argument pour abandonner des accolades. Si votre méthode est trop volumineuse, elle devrait probablement être refactorisée ou restructurée. Faire cela augmentera sans aucun doute la lisibilité plus que simplement enlever des accolades.
afin de garder le code avec des accolades de prendre beaucoup de place, j'utilise la technique recommandée dans le livre Code Complete :
if (...) {
foo();
bar();
}
else {
...
}
Je les omets toujours lorsque cela convient, comme dans votre premier exemple. Le code propre et concis que je peux voir et comprendre en regardant est plus facile à gérer, à mettre au point et à comprendre que le code que je dois faire défiler et lire ligne par ligne. Je pense que la plupart des programmeurs seront d'accord avec cela.
Il est facile pour lui de perdre le contrôle si vous commencez à utiliser plusieurs clauses d'imbrication, if/else et ainsi de suite, mais je pense que la plupart des programmeurs devraient être en mesure de dire où tracer la ligne.
Je le vois un peu comme l'argument de if ( foo == 0 ) vs if ( 0 == foo ). Ce dernier peut empêcher les bogues pour les nouveaux programmeurs (et peut-être même occasionnellement pour les vétérans), tandis que le premier est plus facile à lire et à comprendre rapidement lorsque vous maintenez du code.
La plupart du temps, il s’agit d’une norme de codage, qu’il s’agisse d’une entreprise ou d’un projet FOSS.
En fin de compte, une autre personne devra utiliser votre code et le temps que chaque développeur doit trouver pour définir le style spécifique de la section de code sur laquelle il travaille est une lourde perte de temps.
En outre, imaginez que quelqu'un passe entre Python et une langue Cish plus d'une fois par jour ... In Python l'indentation fait partie de la symant et il serait assez facile de faire une erreur comme celle que vous citez.
Err sur le côté de plus sécurisé - juste un autre bogue que vous n'aurez probablement pas à corriger.
Personnellement, je me sens plus en sécurité si tous mes blocs sont enveloppés dans curlys. Même pour les doubleurs, ces notations sont simples et permettent d’éviter facilement les erreurs. Cela rend le code plus lisible en ce sens que vous voyez clairement ce qu'il y a dans le bloc pour ne pas confondre le corps du bloc avec les déclarations suivantes en dehors du bloc.
Si j'ai un one-liner, je le formate généralement comme suit:
if( some_condition ) { do_some_operation; }
Si la ligne est trop lourde, utilisez ce qui suit:
if( some_condition )
{
do_some_operation;
}
Une méthode alternative qui combine le meilleur des deux mondes est la suivante:
if(foo)
{DoSomething();}
Cela évite toute confusion si la ligne est commentée ou si une autre ligne est ajoutée en dessous.
En outre, nous utilisons MISRA-C comme norme de codage, ce qui oblige toutes les constructions de ce type à utiliser des accolades dans toutes les circonstances.
Ils vous le disent car ils utilisent toujours des éditeurs de code source anciens ou génériques (ne connaissant pas la langue). Si vous utilisez un éditeur avec mise en retrait automatique, vous ne ferez jamais une erreur qui aurait pu être évitée en utilisant des accolades tout le temps.
- Les espaces sont gratuits.
- En fonction de l'indentation pour une lisibilité future, cela dépend des paramètres de l'onglet, ce qui n'est pas une bonne idée. Avez-vous déjà travaillé sur un code vieux de dix ans qui n'était pas sous contrôle de révision?
- Mon expérience est que chaque fois que vous économisez en ne tapant pas d'accolades, vous perdez plus que le temps supplémentaire qu'il me faut pour comprendre ce que vous vouliez dire.
Paul a dit:
Et l'indentation est indépendante de l'utilisation de l'accolade.
Ce n'est pas vrai avec certains styles de codage. Là où je travaille, la norme de codage de la société nous permet de nous passer d’accolades si elles ne sont pas strictement nécessaires; Cependant, la norme de codage nous oblige à mettre en retrait les accolades et leur contenu, nous obtenons donc quelque chose comme ceci:
if (something)
{
for (i = 0; i < count; i++)
{
foo();
}
}
Sans les accolades, cela devient:
if (something
for (i = 0; i < count; i++)
foo();
Avec ce style de codage, en cas d’imbrication profonde, de noms de variable et de fonction longs et que vous utilisez toujours des accolades, vous obtenez beaucoup de code sortant du côté droit de l’écran ou beaucoup de retour à la ligne (IMO). , rendre le code difficile à lire ou à déboguer. Pour cette raison, j'ai toujours tendance à laisser les bretelles à l'extérieur chaque fois que je peux m'en tirer.
Pour ce qui est de mettre une seule déclaration sur la même ligne que le if, les normes de codage de certaines entreprises (la nôtre incluse) l'interdisent, donc ce n'est pas toujours une option.
Si c'était mon choix, je modifierais la norme de codage de la société afin que les accolades soient au même niveau que si, pour, etc. et que la première ligne (ou le commentaire) apparaisse dans le corps sur la même ligne que l'accolade ouvrante, ainsi:
if (something)
{ for (i = 0; i < count; i++)
{ foo();
}
}
Dans ce cas, je serais beaucoup plus disposé (et beaucoup plus probable) à toujours utiliser des accolades (et j'irais même jusqu'à soutenir une règle du "toujours utiliser des accolades"), car chaque paire d'accolades ajouterait une seule ligne supplémentaire et non indentation, le rendant presque aussi compact que de ne pas avoir d'accolades du tout.
Votre programmeur de maintenance peut oublier d'ajouter des accolades ultérieurement s'il ajoute une logique à l'application. Donc, ce qui suit se produit:
if(foo)
bar();
bar(delete);
Au lieu de
if(foo) {
bar();
}
bar(delete);
if ( any ) {
DoSomething();
}
- Si vous pensez que c'est trop gros, vous pouvez l'écrire en une seule ligne:
if ( any ) { DoSomething(); }Si vous pensez qu'une ligne n'est pas lisible aussi bien, vous pouvez l'écrire sur deux lignes:
if ( any ) { DoSomething(); } if ( any ) { DoSomething(); }- À l'avenir, quelqu'un devra changer un énoncé en plusieurs autres. Sans crochets, le changement est plus compliqué. Oui, seulement un peu, mais il vaut mieux prévenir les bugs. Et écrire des crochets est très facile et peu coûteux.
Je ne pense pas qu'omettre des accolades soit toujours une mauvaise pratique, mais si cela devrait être autorisé et dans quelles circonstances doit être convenu au sein de l'équipe.
Je trouve cela très lisible: -
if (foo)
bar();
et ça:-
if (foo)
bar()
else
snafu();
Si une ligne supplémentaire est ajoutée à ceux-ci: -
if (foo)
bar();
snafu();
Cela semble tout faux, il y a un bloc de code, en retrait. mais pas contreventé.
Un argument similaire est valable pour une boucle for. Cependant, lorsque je commence à imbriquer
if (foo)
if (bar)
snafu()
Maintenant, j'ai des ennuis, cela ressemble à un bloc de déclarations. Personnellement, je ne laisserais passer les accolades que pour un niveau, mais plus profondément, je ferais en sorte que le code extérieur utilise des accolades: -
if (foo) {
if (bar)
snafu()
}
Tandis que je tape ceci, j'ai vu les réponses passer de 1 à 17, il s'agit clairement d'une question émotive (je suggère que vous ajoutiez un élément subjectif à la liste de balises (ma capacité de faire cela a disparu). )).
Le plus important est d’avoir un accord au sein de l’équipe sur la question de savoir si et comment elle est acceptable et s’y tenir.
Je détestais moi-même les attelles. Jusqu'au jour où j'ai trouvé une utilisation pour eux. Je travaille sur différentes plates-formes en portant l'application d'une plate-forme à une autre (pour un total de 6). Sous UNIX, si vim est installé, vous pouvez facilement passer à la fin ou au début d’un bloc de code en appuyant sur 'Shift + 5'. Ce sont principalement des blocs ou des boucles if/else.
Donc, si je regardais le problème de Rampion sur vim, je serais totalement perdu et cela me prendrait un certain temps pour bien comprendre le code.
Je pense que tout se résume à la préférence et à la lisibilité. En général, l'ajout d'accolades rendra votre code plus lisible en raison de l'espace supplémentaire entre les lignes contenant le code. En outre, considérons cet exemple (non indenté volontairement):
if (condition1)
if (condition2)
doSomething();
else
doSomethingElse();
Quand est-ce qu'on appelle quelque chose? Lorsque la condition1 est vraie mais que la condition2 est fausse ou la condition1 est fausse? L'ajout d'accolades résout rapidement ce problème de lisibilité et évite toute confusion.
Je suis toujours perplexe quand je vois "ce style permet de gagner de la place".
Étant donné que j’imprime rarement, voire jamais, le code, le gain d’espace ne présente aucun avantage évident: économiser quelques octets sur le disque n’en vaut pas la peine et je ne paye pas pour l’espace pris à l’écran.
Certaines personnes trouvent le code compact plus lisible, je ne dirai pas que non (très subjectif), mais en tant qu’artiste amateur et typographe, j’apprécie grandement l’utilisation des espaces blancs ...
Je ne répéterai pas les arguments ci-dessus, mais j'ajouterai, je pense, de la cohérence: je n'aime pas le code comme
if (foo)
{
// Lot of code
}
else
DoStuff();
Ceci dit, parfois je ne me livre pas d'accolades: dans des conditions de garde, quand je sors de bonne heure:
if (somethingBadHappened)
return;
Pour résumer, je pense que l'ajout (presque) systématique de crochets autour d'un code important améliore la lisibilité (le code "respire", ce n'est pas exagéré), la cohérence et peut éviter certaines erreurs stupides (oui, ce genre d'erreur est évident, mais le codeur est humain. (en général), peut être fatigué, débutant, sous stress ...).
J'ai créé une macro Lua pour que SciTE ajoute ces accolades autour de tout bloc de code ou de ligne en cours, en une frappe et une mise en retrait correcte: cela ne me coûte rien.
Maintenant, je ne vous poursuivrai pas en justice si vous choisissez d'omettre ces accolades. Comme d'autres le soulignent, l'une ou l'autre option peut être définie dans les règles de codage. A chacun ses goûts.
C'est un compromis de code plus court (mieux lisible) que de code plus sécurisé (moins sujet aux erreurs).
Mes 2 centimes:
- Il y a une raison à cette règle. Il a été développé par d'innombrables programmeurs au cours de longues heures de travail, allant jusque dans la nuit ou le lendemain matin, pour tenter de réparer un bug causé par un petit oubli.
- Vous avez décidé vous-même si le commerce en vaut la peine.
- D'après mon expérience, je suis l'un de ces innombrables programmeurs qui travaillaient jusque tard dans la nuit pour trouver la cause d'un mauvais virus. La cause était moi paresseux.
J'aime aussi le formatage plus compact. C'est pourquoi je tape constamment Ctrl + K, Ctrl + D pour reformater dans Visual Studio. Je souhaite juste pouvoir le faire faire pour moi après chaque pression sur une touche.
D'un côté, je laisse les supports pour une seule déclaration. D'autre part, je vérifie tout le code C avec PC-Lint ( http://www.gimpel.com/ ), qui marque deux ou plusieurs lignes en retrait suivant une instruction if () comme "suspect". échancrure".
Soit dit en passant, placer des instructions simples sur la même ligne que if () semble une bonne idée.
Parce que StyleCop le dit bien.
Si vous pensez "parfois", il est utile d'avoir des accolades, vous devriez toujours les ajouter pour qu'elles soient consistantes. Les programmes doivent être écrits pour être lus par des personnes et non par des ordinateurs. Je préfère des bretelles comme:
if (mybool)
{
doMyStuff();
}
else
{
doMyOtherStuff();
checkStuff();
}
et pas comme
if (mybool) {
doMyStuff();
}
else {
doMyOtherStuff();
checkStuff();
}
et pas comme
if (mybool)
doMyStuff();
else
{
doMyOtherStuff();
checkStuff();
}
J'utilise toujours des accolades, sauf sur la déclaration la plus interne, en supposant que la déclaration la plus interne est une doublure. Donc, mon code ressemble à:
for (int i=0; i<10; i++)
{
for (int x=0; x<20; x++)
{
if (someBoolValue)
DoThis(x,y);
}
}
L'autre exception est bien entendu, empilés à l'aide d'instructions.
Il n'y a absolument aucun sens à écrire
using (Stream x = File.Open(...))
{
using (Stream y = File.Create(...))
{
...
}
}
quand tu peux écrire
using (Stream x = File.Open(...))
using (Stream y = File.Create(...))
{
....
}
Sur une autre pensée, si vous supprimez/n'utilisez pas d'accolades pour enregistrer des lignes, vous devez refactoriser le code.
Ok, il m’a toujours semblé que c’était plus une préférence personnelle. J'ai remarqué cependant que pour la lisibilité, il vaut mieux avoir {} que de ne pas les avoir. J'ai remarqué avec ReSharper que ReSharper a tendance à les supprimer et à faire le plus grand nombre d'entre vous si des énoncés comme celui-ci
if(this == yes)
DoSomething();
Mais par souci de lisibilité je fais toujours
if(this == yes)
{
DoSomething();
}
Bien qu'avec une seule ligne de code dans l'instruction "if", la lisibilité de l'instruction ne soit pas vraiment différente, mais si vous mettez 20 à 30 lignes de code dans une instruction if, il est alors plus facile de lire avec le {} et de laisser moins de place à l'erreur. bugs dans votre code.