Pourquoi est-il considéré comme une mauvaise pratique pour omettre les accolades?
Pourquoi tout le monde me dire de l'écriture de code, comme c'est une mauvaise pratique?
if (foo)
Bar();
//or
for(int i = 0 i < count; i++)
Bar(i);
Mon plus gros argument pour omettre les accolades, c'est qu'il peut parfois être deux fois autant de lignes avec eux. Pour exemple, voici un code pour peindre un effet de lueur d'un label 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 de chaînage usings
ensemble sans avoir à tiret d'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 commun pour des accolades tourne autour de maintenance de la programmation, et les problèmes qui en découleraient par l'insertion de code entre l'original en cas de déclaration et de son résultat:
if (foo)
Bar();
Biz();
Questions:
- Est-il de mal à vouloir utiliser la syntaxe compacte dont la langue n'offre? Les personnes qui conçoivent ces langues sont intelligents, je ne peux pas imaginer qu'ils allaient mettre une caractéristique qui est toujours mauvais d'utilisation.
- Doit-on ou ne devrait-on pas écrire de code de sorte que le plus petit dénominateur commun peut comprendre et n'ont aucun problème à travailler avec elle?
- Est là un autre argument que je suis absent?
- Cela vient à travers plus comme un coup de gueule qu'une question. C'est comme vous dites, "je sais pourquoi c'est mauvais mais je n'ai pas de soins."
- J'ai donné ce que je pense est l'argument le plus commun contre mon cas. Je fais une demande pour d'autres raisons pourquoi j'ai peut-être tort.
- Argumentatif? Pourriez-vous la reformuler? La réponse que vous avez donné et la réponse la dessus personne a donné sont "la réponse", de sorte que votre question est vraiment de l'auto-répondeur.
- Ils ne sont pas "la solution". Je suis à la recherche d'autres réponses, car je pense que le plus commun est le mal. Par exemple, Torlack a donné un exemple C++ à propos des macros.
- Je suis d'accord avec vous. Les omettre. Période.
- L'utilisation de Python et d'oublier à ce sujet 🙂
- ...ou de l'utilisation VB.NET et oubliez aussi ;-P
- QUI SE SOUCIE DE LA FAÇON DONT DE NOMBREUSES LIGNES DE QUELQUE CHOSE EST À L'EST EN 2010. Les moniteurs sont à l'échelle et à bas prix et de haute résolution! Mon moniteur est de 2048 X 1152 et j'ai DEUX d'entre eux! La lisibilité est bien plus important qu'une économie de 2 lignes verticales quand vous pouvez facilement introduire subtiles erreurs qui sont difficiles à trouver.
- J'utilise des accolades pour les conditions. Je n'ai jamais utilisé (c'est pourquoi c'est un commentaire et pas de réponse), mais trouvé très intéressant le pas-accolade pour "l'aide" de l'énoncé, je pense qu'il clarifie la lecture.
- Les moniteurs sont à l'échelle et à bas prix, mais ils ne sont pas de haut et de bas prix. L'espace Vertical est de plus en plus rares qu'à l'horizontale de l'espace.
- Tourner de côté 🙂
- Afin de ne pas bousiller comme Apple avec le SSL bug découvert en Février 2014, LOL.
- L'empilement de l'usage sans accolades ne compilera pas si vous ajoutez une instruction entre eux, tout en omettant des accolades sur les conditions de compiler, même si vous ajoutez/supprimez une déclaration directement à la suite de la
if
déclaration. Dans un cas, l'omission d'accolades ne peut pas provoquer une erreur d'exécution, dans l'autre, d'une omission peut facilement provoquer une erreur d'exécution. - Si vous avez été sérieux au sujet de la réduction des lignes de code, vous pouvez utiliser cette construction:
foo && bar();
au lieu d'une seule ligne si-états,foo ? doSomething() : doSomethingElse()
au lieu d'une seule ligne si-sinon-déclarations, etc. Hélas, la plupart des gens ne sont pas vraiment sérieux au sujet de la réduction des lignes de code. 🙂 - Oups, raté le C# tag.
- Si votre plus grand argument est le nombre de lignes est quelque chose de mal avec votre façon de penser sur le code 🙂
- Extra accolades sont pour les personnes avec un mauvais indentation: elles se perdent et habituellement ne sais pas qui -par exemple - tout "autre" appartient à la plus proche de "si".
- Re: "QUI se SOUCIE de la FAÇON dont de NOMBREUSES LIGNES de quelque CHOSE EST à l'EST", code Consolidé le rend beaucoup plus facile à lire lorsque le débogage javascript dans les navigateurs lors de l'affichage du site. Et si c'est de l'argument, pourquoi utiliser des fonctions d'assistance à tous?
- En réduisant le nombre de lignes n'est pas question de réduire le nombre de lignes. C'est à propos de la lisibilité du code. C'est aussi la réponse à pourquoi écrire
foo && bar();
est généralement mauvais. - exactement.
- C'est seulement considéré comme mauvais par des personnes qui ont besoin d'apprendre comment analyser le code mieux. Et comme quelqu'un l'a déjà mentionné, si elles ont un problème sans {} alors, qu'en est ternaire opérateurs? L'exemple n'est même pas imbriquée! @martinkunev Que l'école de la pensée et de l'similaires est donc très limitée. Trop binaire. Oui, oui, boolean tend pour 1 ou 0, mais c'est le résultat de l'exploitation. Le seul problème avec du code comme ça, c'est ... ça dépend de trop de variables. Mais je connais des gens aussi froncer les sourcils à l'encontre d'un code comme: if ((s=socket(...))<0) mais je n'ai jamais eu un problème lors de la lecture d'un tel code. Style débats sont à aboyer.
Vous devez vous connecter pour publier un commentaire.
En fait, le seul temps qui ne l'a jamais vraiment peu de moi quand j'étais débogage, et commenté dans le bar():
Autre que cela, j'ai tendance à utiliser:
Qui prend en charge les cas ci-dessus.
MODIFIER Merci pour la clarification de la question, je suis d'accord, il ne faut pas écrire du code pour le plus petit dénominateur commun.
Vitesse de lecture...
L'écart de ce qui a déjà été mentionné. À ce stade, j'ai déjà été conditionnés à analyser si les déclarations avec des accolades et des espaces blancs. J'ai donc lu:
Légèrement plus rapide que j'ai lu:
Je l'ai lu un peu plus lent si ça ressemble à ça:
J'ai lu cet significativement plus lente que la précédente:
beause je ne peux pas m'empêcher de le lire encore une fois juste en-cas et je me demande si l'auteur a l'intention de:
Déjà couverts en général, mais quand il s'agit de lecture ci-dessous, je vais être à la recherche dans ce pour un certain temps assurez-vous que ce que l'auteur veut. Je peut même traquer l'auteur original pour confirmer.
if (condition) {newline} DoSomething(); {newline x2} DoSomething();
? Je trouve que moins verbeux que 2 curlies pour un seul cas. Je trouve (quand ils sont longs) une ligneif (condition) dosomething
plus difficile à lire, mais je pense que je suis dans la minorité, il yif (badCondition) return;
Il n'est pas toujours pratique de refactoriser le code dans unor
conditionnelle.Si c'est quelque chose de petit, de l'écrire comme ceci:
Si il est assez long à se casser en deux lignes, utiliser des accolades.
J'ai aussi l'habitude de penser que c'est mieux d'utiliser seulement des accolades lorsque c'est vraiment nécessaire. Mais pas plus, la principale raison, lorsque vous avez beaucoup de code, il ne le rendre plus lisible et vous pouvez l'analyser sur le code plus rapide quand vous avez un uniforme de contreventement style.
Une autre bonne raison pour toujours à l'aide d'accolades, d'ailleurs quelqu'un l'ajout d'une deuxième déclaration de la si, c'est quelque chose comme cela pourrait se produire:
Avez-vous remarqué que la clause else est en fait celle de la "si(b)"? Vous n'avez probablement, mais auriez-vous confiance en personne pour se familiariser avec cette chasse aux sorcières?
Donc, si c'est juste pour des raisons de cohérence et parce que vous ne savez jamais ce que, des choses inattendues peuvent se produire lorsque quelqu'un d'autre (c'est toujours les autres qui sont stupides) modifie le code, j'ai toujours mettre des accolades, parce que ça rend le code source plus lisible, plus rapide à analyser par votre cerveau. Seulement pour le plus simple si les déclarations, comme un cas où une délégation est faite ou est de type commutateur, où vous savez que la clause ne sera jamais étendu, je laisserais les accolades.
!a || !b
) que ce soit avec (!a
) ou sans (a && !b
) ajouté des accolades.else
la priorité va toujours au plus procheif
clause lors pas de crochets existent? Sens (tu dois choisir quelque chose), mais je me demande ce que les gens l'habitude de faire avant de claviers avait crochets.NOP
? ;^)Je préfère la clarté de l'accolade offre. Vous savez exactement ce que l'on entend et ne pas avoir à deviner si quelqu'un juste raté son coup et laissé au large (et a introduit un bug). La seule fois où je les omettre, c'est quand j'ai mis le si et l'action sur la même ligne. Je ne fais pas ça très souvent. Je préfère les espaces introduits par mettre de l'accolade sur sa propre ligne, mais à partir des années de K&R, C-comme la programmation, la fin de la ligne avec un corset est une pratique que j'ai à travailler pour surmonter si l'IDE n'a pas l'appliquer pour moi.
Ce n'est pas toujours considéré comme une mauvaise pratique. Le Mono Projet De Directives De Codage suggère de ne pas utiliser d'accolades si il n'est pas nécessaire. De même pour le GNU Normes de Codage. Je pense que c'est une question de goût personnel, comme toujours avec les normes de codage.
Lignes sont bon marché. La puissance du processeur n'est pas cher. Le temps du développeur est très cher.
En règle générale, à moins que je suis en train d'élaborer absolument ressources /vitesse d'applications critiques, je serais toujours pencher du côté de l'écriture de code qui est
(a) Facile pour n'importe quel autre développeur de suivre ce que je fais
(b) Commentaire des parties spécifiques du code qui peuvent en avoir besoin
(c) Facile à déboguer si quelque chose va mal
(d) Facile à modifier si elle doit l'être à l'avenir (c'est à dire l'ajout /suppression de code)
La vitesse ou académique, l'élégance du code est secondaire par rapport à ces facteurs à partir d'un point de vue commercial. Ce n'est pas de dire que je me suis mis à écrire maladroit ou laid code, mais c'est MON ordre de priorité.
En omettant d'accolades dans la plupart des cas, pour moi, rend (b), (c) et (d) plus difficile (note n'est pas impossible cependant). Je dirais que l'utilisation d'accolades ou pas n'a pas d'effet sur (a).
Je pense que c'est une question de lignes directrices pour le projet sur lequel vous travaillez et de goût personnel.
J'ai l'habitude de les ignorer quand ils ne sont pas nécessaires, sauf dans certains cas comme les suivants:
je préfère
L'un des cas où cela peut vous mordre est de retour dans les vieux jours de C/C++ macros. Je sais que c'est un C# question, mais souvent les normes de codage de transporter sans les raisons pour lesquelles la norme a été créée en premier lieu.
Si vous n'êtes pas très prudent lorsque vous créez des macros, vous pouvez finir par causer des problèmes si les états qui n'utilisent pas les {}.
Maintenant, ne vous méprenez pas, je ne dis pas que vous devriez toujours faire {} juste pour éviter ce problème en C/C++, mais j'ai eu à traiter avec de très étranges bugs à cause de cela.
Je pensais la même façon.
Jusqu'à ce qu'un jour ( pourquoi faut-il toujours que "un jour" qui changera votre vie à jamais? ) nous passer de 24 à 36 heures d'affilée sans dormir débogage de code de production seulement pour trouver quelqu'un de ne pas mettre des accolades combinée avec une recherche/remplacement de changement.
C'était quelque chose comme cela.
Ce qui est venu après, c'est
Il s'avère que le système génère des 500 mo de journaux quotidiens et nous ont demandé de l'arrêter. L'indicateur de débogage n'était pas assez pour une recherche et remplacer println était dans l'ordre.
Encore lorsque l'application est allé à la production de l'indicateur de débogage a été désactivé et l'importance des "saveDayData" n'a jamais été appelé.
MODIFIER
Maintenant, le seul endroit où je ne suis pas d'utiliser les accolades est en si/d'essayer de construire.
Après avoir regardé une superstar développeur de le faire.
Je suis très heureux d':
Personnellement, je ne vois pas pourquoi
est plus lisible.
Oui, les lignes sont gratuits, mais pourquoi devrais-je avoir à faire défiler des pages et des pages de code alors qu'il pourrait être la moitié de la taille?
Si il y a une différence dans la lisibilité ou la maintenabilité puis, bien sûr, mettre des accolades... mais dans ce cas je ne vois pas de raison de le faire.
Aussi, je vais toujours mettre des accolades pour si imbriquées est là que j'ai imbriqué d'autre
vs
est terriblement confus, j'ai donc toujours écrire comme:
Chaque fois que possible, j'utilise des opérateurs ternaires, mais je jamais les imbriquer.
Pour être franc je le vois comme:
De bons programmeurs programme défensivement, Mauvais programmeurs ne.
Puisqu'il y a plusieurs exemples ci-dessus, et de mes propres expériences similaires avec des bugs liés à oublier les accolades puis j'ai appris à la dure à TOUJOURS METTRE des ACCOLADES.
Autre chose est de choisir le style personnel de la sécurité et c'est clairement la mauvaise programmation.
Joel même mentionne cela dans De Faire Les Mauvais Code Regarde Mal
Une fois que vous obtenez un peu par un bug à cause de manque des accolades, vous apprenez qu'il manque des accolades regard mauvais, parce que, vous savez, c'est un lieu potentiel pour un autre bug à se produire.
if
contrôle d'un bloc, mais d'éviter la nécessité d'un bloc dans le cas où unif
contrôle d'une seule action plutôt que d'un bloc.Je suis d'accord que "si vous êtes assez intelligent pour demander à quelqu'un de vous payer pour écrire le code, vous devez être assez intelligent pour ne pas compter uniquement sur l'indentation pour voir le déroulement du code."
Toutefois, des erreurs peuvent être commises, et c'est une douleur pour déboguer... surtout si vous venez de regarder quelqu'un d'autre code.
Ma philosophie est que si elle rend le code plus lisible, pourquoi ne pas le faire?
Évidemment, vous devez tracer une ligne quelque part, comme la conclusion que le juste milieu entre concis et trop descriptif, les noms de variables. Mais les supports vraiment éviter les erreurs et d'améliorer la lisibilité du code.
Vous pouvez argumenter que les gens assez intelligents pour codeurs vont être assez intelligent pour éviter les bugs que les souches bracketless consolidés. Mais pouvez-vous honnêtement dire que vous n'avez jamais été déclenché par quelque chose d'aussi simple que d'une erreur d'orthographe? Minutie, comme cela peut être écrasante quand on regarde les grands projets.
Il y a toujours des exceptions, mais je dirais contre omettre les accolades, seulement lorsqu'il est sous l'une des formes:
Sinon, je n'ai pas de problème avec ça.
J'ai parfois utiliser le fond même code (à l'aide de plusieurs états), mais d'autres que j'ai toujours mettre les accolades dans les. Je viens de trouver ça rend le code plus clair. Il est flagrant de plus que juste l'indentation qu'une déclaration est partie d'un bloc (et donc probablement partie d'une si etc).
J'ai vu le
piqûre d'insecte moi (ou plutôt "moi et les collègues" - je n'ai pas fait introduire le bug) une fois. Cela malgré le fait que nos normes de codage au moment recommandé d'utiliser des accolades partout. Il m'a fallu très longtemps pour spot - parce que vous voyez, ce que vous voulez voir. (C'était il ya 10 ans. Peut-être que je l'avais trouvé plus vite maintenant.)
Bien sûr, si vous utilisez "accolade à la fin de la ligne", il réduit les lignes supplémentaires encourus, mais personnellement, je l'aversion que le style de toute façon. (Je l'utilise au travail, et l'ai trouvé moins désagréable que ce que j'attendais, mais c'est toujours un peu désagréable.)
Je suis impressionnée et émue que mes pairs dans ce domaine de la programmation informatique (beaucoup) ne sont pas rebutés par la perspective d'éventuels bugs lorsque vous ignorez les accolades sur une seule ligne de blocs.
Je suppose que cela signifie que je ne suis pas intelligent. J'ai fait des erreurs autour de ce à plusieurs reprises. J'ai débogué les erreurs des autres autour de cela. J'ai regardé logiciel navire avec des bugs à cause de cela (RDP vers un ordinateur exécutant VS2002 et votre fenêtre de surveillance de la police ira bancale).
Si je regarde toutes les erreurs que j'ai fait qui aurait pu être évité avec un changement de style de codage, la liste est très longue. Si je n'avais pas changé mon approche dans chacun de ces cas, je n'aurais probablement jamais fait en tant que programmeur. Encore une fois, je suppose que je ne suis pas intelligent. Pour compenser, j'ai été un fervent utilisateur de croisillons sur une seule ligne de blocs pour une longue période de temps.
Cela dit, certaines choses ont changé dans le monde, qui rendent le "tu devras utiliser des accolades sur une seule ligne de blocs" règle moins pertinent aujourd'hui que lorsque Moïse a amené jusqu'à nous:
Certaines langues populaires faire de la question de s'en aller en faisant de l'ordinateur de lire l'indentation, tout comme le programmeur n' (par exemple en Python).
Mon éditeur automatiquement les formats de pour moi, donc les chances de moi en train de tromper par indentation est beaucoup plus réduite.
TDD signifie que si j'introduis un bug, parce que je me confondre en un seul bloc de lignes, je suis beaucoup plus susceptibles de découvrir le bug rapidement.
De Refactoring et de la langue de l'expressivité dire que mes blocs sont beaucoup plus courts, et une seule ligne de blocs arrive beaucoup plus souvent qu'à l'habitude. Hypothétiquement, avec une application impitoyable de ExtractMethod, je pourrais éventuellement avoir seulement seule ligne de blocs dans l'ensemble de mon programme. (Je me demande de quoi ça pourrait ressembler?)
En fait, il y a un avantage distinct peut venir de refactoring impitoyablement & omettre les accolades sur une seule ligne de blocs: quand vous voyez des accolades, un peu d'alarme peuvent aller dans votre tête qui dit "la complexité ici! méfiez-vous!". Imaginez si c'était la règle:
J'ouvre moi-même à l'idée de changer ma convention de codage de quelque chose comme "une seule ligne de blocs avez peut-être jamais accolades" ou "si vous pouvez mettre le bloc sur la même ligne que l'état, et il s'adapte à tous à moins de 80 caractères, omettre les accolades". Nous allons le voir.
En œuvre des trois conventions:
et:
et (qui représentent tout style d'indentation à l'aide d'une ouverture et d'une accolade de fermeture):
Je préfère le dernier aussi:
Vos principaux arguments contre l'utilisation de l'appareil qu'ils utilisent des lignes supplémentaires et qu'ils nécessitent un supplément de mise en retrait.
Lignes sont (presque) gratuit, en minimisant le nombre de lignes dans votre code ne doit pas être un objectif.
Et de l'indentation est indépendant de l'orthèse d'utilisation. Dans votre en cascade à l'aide de l'exemple, je pense toujours que vous devriez être mise en retrait, même lorsque vous omettre les accolades.
Je suis un croyant ferme dans l'écriture soignée et code concis, mais je serais toujours utiliser des accolades. Je trouve qu'ils sont un moyen pratique de rapidement voir le cadre dans lequel une ligne de code. Il n'y a pas d'ambiguïté, c'est juste explicitement en face de vous.
Certains peuvent dire que c'est une affaire de préférence, mais je trouve que le déroulement logique d'un programme beaucoup plus facile à suivre si c'est cohérent, et je ne crois pas qu'il est conforme à écrire une instruction if comme cela;
Et un autre comme cela;
Je préfère en choisir un style général et le bâton avec elle 🙂
L'un des principaux problèmes, c'est quand vous avez régions de one-liners et non un seul doublures,
avec la séparation du contrôle de tresorerie (
for
,if
, qu'avez-vous) et la fin de la tresorerie.Par exemple:
J'ai utilisé pour être un fervent partisan de "accolades sont un must!", mais depuis l'adoption de tests unitaires, je trouve que mes tests unitaires protéger braceless consolidés à partir des scénarios tels que:
Avec de bons tests unitaires, je peux en toute confiance omettre les accolades pour de simples déclarations pour améliorer la lisibilité (oui, cela peut être subjectif).
Sinon, pour quelque chose comme ci-dessus, je serais probablement inline qui ressemble à:
De cette façon, le développeur qui a besoin d'ajouter de la barre() à la condition, serait plus apte à reconnaître le manque d'accolades, et les ajouter.
Utilisation de certains personnels de jugement.
est bien par lui-même. Sauf si vous êtes vraiment inquiet à propos de crétins mettre dans quelque chose comme ceci plus tard:
Si vous n'êtes pas inquiet au sujet de crétins, vous êtes fine (je ne suis pas -- si ils ne peuvent pas obtenir le code de base de la syntaxe de droit, c'est le moindre de leurs problèmes)>
En échange, c'est beaucoup plus lisible.
Le reste du temps:
Qui a été mon préféré de loin que je me souvienne. En outre:
Fonctionne pour moi.
Verticale de l'espace en lui-même n'est pas très pertinente, la lisibilité est. L'accolade d'ouverture sur une ligne s'arrête juste à la conversation d'un élément syntaxique, jusqu'à ce que votre œil se déplace vers la ligne suivante. Pas ce que j'aime.
if (parameter == null) return null;
.Bon d'accord, c'est une vieille question qui a été posée à la mort. J'ai quelque chose à ajouter.
D'abord, j'ai juste à dire UTILISER LES ACCOLADES. Ils ne peuvent aider à la lisibilité, et de la lisibilité (pour vous et les autres!) devrait être très élevé sur votre liste de priorité, sauf si vous êtes à la rédaction de l'assemblée. Illisible code toujours, toujours conduit à des bugs. Si vous trouvez que les accolades de rendre votre code prennent trop de place, vos méthodes sont probablement trop long. La plupart ou la totalité de la méthode, doit s'inscrire dans l'une hauteur de l'écran si vous le faites à droite, et de Trouver (F3) est votre ami.
Maintenant, pour mon plus: Il y a un problème avec ceci:
Essayez de définir un point d'arrêt, qui ne sera touché si la barre() va exécuter. Vous pouvez le faire en C#, en mettant le curseur sur la deuxième moitié du code, mais ce n'est pas évident et c'est un peu de douleur. En C++, vous ne pouviez pas le faire du tout. L'un de nos plus anciens développeurs de travailler sur du code C++ insiste sur la rupture des "si", les déclarations en deux lignes pour cette raison. Et je suis d'accord avec lui.
Donc faire ceci:
Disons que vous avez un peu de code:
et puis quelqu'un d'autre arrive et ajoute:
Selon la façon dont c'est écrit, bar(); est maintenant exécutée de manière inconditionnelle. En incluant les accolades, vous éviter ce genre d'erreurs accidentelles. Le Code doit être écrit de telle manière à faire de telles erreurs difficile ou impossible à faire. Si je faisais une revue de code, et vu le manque des accolades, en particulier réparties sur plusieurs lignes, je voudrais créer un défaut. Dans les cas où elle est justifiée, le tenir sur une seule ligne, de sorte que les chances de faire une telle erreur est de nouveau maintenu à un minimum.
La réduction des lignes n'est pas vraiment un bon argument de l'abandon des accolades. Si votre méthode est trop grand, il doit probablement être remaniée en petits morceaux ou restructurés. Faire cela va sans aucun doute augmenter la lisibilité plus que de simplement prendre des accolades.
afin de conserver le code avec des accolades de prendre beaucoup de place, j'utilise la technique recommandée dans le livre Le Code Complet:
if
qui est suivie par un simple retrait de la ligne peut être visuellement reconnu que le contrôle d'un état unique, sans croisillons. L'open-brace-par-lui-même de style permet donc d'économiser les espaces dans la situation où unif
contrôle de quelque chose qui est sémantiquement une seule action (comme distincts à partir d'une séquence d'étapes qui arrive à contenir une seule étape). Par exemple,if (someCondition)
/ ` throw new SomeException(...)`.J'ai toujours omettre lors de l'appropriés, comme dans votre premier exemple. Propre, concis code que j'ai de voir et de comprendre en parcourant est plus facile à maintenir, de débogage et de comprendre que le code que j'ai pour faire défiler et lire ligne par ligne. Je pense que la plupart des programmeurs seront d'accord avec cela.
Il est facile pour elle de sortir de la main si vous commencez à faire des multiples de nidification, si/d'autre des clauses 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 la
if ( foo == 0 )
vsif ( 0 == foo )
. Celui-ci peut empêcher les insectes pour les nouveaux programmeurs (et peut-être même à l'occasion pour les anciens combattants), alors que le premier est plus facile de rapidement lire et à comprendre quand vous êtes à la mise à jour du code.La plupart du temps il est ancré comme une norme de codage, que ce soit pour une entreprise ou un FOSS projet.
En fin de compte quelqu'un d'autre aura besoin d'analyser votre code, et il est l'un des principaux temps de vidange pour chaque développeur d'avoir à comprendre le style spécifique de la section de code ils travaillent.
Aussi, imaginez que quelqu'un entre Python et un Cish langue plus d'une fois par jour... Dans l'indentation de Python est la partie du bloc symantics de la langue, et il serait assez facile de faire une erreur comme celle que vous citez.
Err sur le côté de plus sûr, un bug plus vous n'aurez pas à résoudre.
Personnellement, je se sentir plus en sécurité si tous mes blocs sont enveloppés dans des curlys. Même pour les one-liners, ce sont de simples notes facilement éviter les erreurs. Elle rend le code plus lisible dans le sens que vous voyez clairement ce qui est dans le bloc de ne pas confondre le corps du bloc avec les énoncés suivants à l'extérieur du bloc.
Si j'ai un one-liner, en général, je le formater comme suit:
Si la ligne est tout simplement trop lourd puis utilisez la commande suivante:
Une méthode alternative qui combine le meilleur des deux mondes est ceci:
Cela évite toute confusion si la ligne est un commentaire, ou d'une autre ligne est ajoutée en dessous.
Aussi, nous utilisons MISRA-C comme une norme de codage, qui exige que toutes les constructions de ce genre pour utiliser des accolades en toutes circonstances.
Ils vous disent parce qu'ils utilisent encore l'ancienne ou générique (non dépendant de la langue) source des éditeurs de code.
Si vous utilisez un éditeur de texte avec retrait auto, vous n'aurez plus jamais faire une erreur qui aurait pu être évité en utilisant des accolades de tous les temps.
Votre maintenance programmeur peut oublier d'ajouter des accolades plus tard si il/elle ajoute la logique de l'application. Donc ce qui suit se produit:
Au lieu de
Je ne pense pas que l'omission accolades est toujours une mauvaise pratique, mais si il doit être admis et dans quelles circonstances doit être accepté dans l'équipe.
Je trouve cela très lisible:-
et ce:-
Si une ligne supplémentaire est ajouté à ceux-ci:-
Cela ressemble tout faux, il y a un bloc de code, en retrait. mais pas étayée.
Le même raisonnement tient pour une boucle for. Cependant, quand j'ai commencer nidification:-
Maintenant, je suis en cours d'exécution dans la difficulté, il ressemble à un bloc d'instructions. Personnellement, je ne passe que l'utilisation des accolades pour un seul niveau plus profondément un je ferais l'extérieur de code à utiliser des accolades:-
Que je suis en tapant ce que j'ai vu les réponses saut de 1 à 17, manifestement, cela va être une question émotive (je vous suggère d'ajouter subjective à la liste des tags (ma capacité à faire ce qui a disparu ce qui se passe avec ça?)).
La chose la plus importante est d'avoir l'accord de l'équipe quant à savoir si et comment son acceptable et rester avec elle.
Je pense que tout se résume à la préférence et de la lisibilité. Généralement en ajoutant des accolades permet de rendre votre code beaucoup plus lisible en raison de l'espace supplémentaire entre les lignes avec le code. Aussi, prenons cet exemple (pas de retrait sur la fin):
Quand doSomethingElse appelée? Lors de la condition1 est vrai, mais la condition2 est fausse, ou lors de la condition1 est faux? En ajoutant des accolades rapidement résout ce problème de lisibilité et permet d'éviter la confusion.
Je détestais les accolades moi-même. Jusqu'à ce qu'un jour, j'ai trouvé une utilisation pour eux. Je travaille sur différentes plates-formes de transfert de la demande de plate-forme à plate-forme (travail sur 6 au total). Sur UNIX si vous avez vim installé, alors vous pouvez facilement sauter à la fin ou au début d'un bloc de code en appuyant sur "Shift + 5'. Ces la plupart sont si/d'autre des blocs ou des boucles.
Donc, si je regarde la Rampion problème sur vim, je serais totalement perdu et va me prendre un certain temps pour comprendre pleinement le code.
Paul a dit:
Ce n'est pas vrai avec certains styles de codage. Là où je travaille, la société norme de codage permet de le faire sans accolades si elles ne sont pas strictement nécessaires; toutefois, la norme de codage nous fait tiret, les accolades ainsi que ce qui est en eux, donc nous retrouver avec quelque chose comme ceci:
Sans les accolades, cela devient:
Avec ce style de codage, quand il est au plus profond de nidification, avec la variable et les noms de fonction et de toujours utiliser des accolades, vous pouvez soit le faire beaucoup de code va sur le côté droit de l'écran ou d'un lot de la ligne d'emballage, qui, de l'OMI, rendre le code plus difficile à lire ou de débogage. Pour cette raison, j'ai toujours tendance à laisser les accolades chaque fois que je peut faire.
Comme pour mettre une simple déclaration sur la même ligne que le if, certaines normes de codage (y compris les nôtres) ne plaise que, donc, il n'est pas toujours une option.
Si c'était mon choix, je voudrais changer la société norme de codage d'avoir les accolades de niveau avec le if, for, etc. et la première ligne (ou un commentaire) dans le corps, sur la même ligne que l'accolade d'ouverture, donc:
Je serais beaucoup plus disposés (et beaucoup plus probable) à toujours utiliser des accolades, alors (et pourrait même aller jusqu'à soutenir un "toujours utiliser des accolades" la règle), parce que chaque paire d'accolades permettrait d'ajouter une seule ligne supplémentaire et sans indentation, il est presque aussi compact comme n'ayant pas de broches.
pouvez l'écrire en une seule ligne:
Si vous pensez que, dans une ligne n'est pas lisible si bon, vous pouvez l'écrire en deux lignes:
une déclaration de plus de déclarations.
Sans crochets est la variation de la plus
compliqué. Oui seulement littlebit, mais
vaut mieux éviter les bugs. Et de l'écriture
entre parenthèses est très facile, un moyen pas cher.
C'est un tradeof, plus courte de code (mieux lisible) par rapport à du code plus sûr (moins enclins à faire des erreurs).
Mes 2 cents:
Ok, il m'a toujours semblé que c'est plus une préférence personnelle pour moi. J'ai remarqué cependant, pour des raisons de lisibilité, il est préférable d'avoir { } alors de ne pas en avoir. J'ai un avis à l'aide de ReSharper que ReSharper tend à supprimer et la plupart d'entre vous si ce type de déclarations
Mais pour plus de lisibilité je fais toujours
Bien qu'avec une seule ligne de code dans l'instruction "if" de la lisibilité n'est pas vraiment différent, mais si vous mettez 20 à 30 lignes de code dans une instruction if, alors il est plus facile à lire avec les {}, et ça laisse moins de place à l'erreur et des bugs dans votre code.
Je suis toujours perplexe quand je vois "ce style d'économiser de l'espace".
Depuis que j'ai rarement, sinon jamais, d'imprimer des code, gain d'espace n'a pas d'avantage évident pour moi: économiser quelques octets sur le disque ne prend pas en vaut la peine, et je ne paie pas pour un espace sur l'écran.
Certaines personnes trouvent compact code plus lisible, je ne soutiennent pas cette (très subjectif), mais comme artiste amateur et typograph, j'ai fortement valeur les espaces d'utilisation...
Je ne vais pas répéter les arguments ci-dessus, mais je vais l'ajouter, je pense, de la cohérence: je n'aime pas le code comme
Cela dit, j'ai parfois se livrer à pas de broches: dans les conditions de la garde, quand je fais une sortie anticipée:
Pour résumer, je pense que l'ajout d' (presque) systématiquement des accolades autour de code importante améliore la lisibilité du code ("respire", n'est pas à l'étroit), de la cohérence, et peut-être d'éviter quelques erreurs stupides (oui, ce genre d'erreur est évidente, mais codeur est de l'homme (en général), peut-être fatigué, débutant, moins de stress,...).
J'ai fait un Lua macro pour SciTE pour ajouter ces accolades autour de n'importe quel bloc de code ou de la ligne en cours, avec une frappe et d'indentation: il coûte vraiment rien pour moi.
Maintenant, je ne vais pas vous poursuivre si vous avez choisi d'omettre ces accolades. Comme l'autre, l'un ou l'autre peut être définie dans les règles de codage. À chacun son propriétaire.
D'une part, je laisse les accolades pour une seule instruction. Sur l'autre main, je vérifie tous les code C avec PC-Lint (http://www.gimpel.com/), qui les drapeaux de deux ou plusieurs lignes en retrait à la suite d'une instruction if() comme "suspect indentation".
Par la voie, en mettant unique des déclarations sur la même ligne que le if() ressemble à une bonne idée.
J'ai toujours utiliser des accolades, sauf sur la partie intérieure de la plupart déclaration, en supposant que la plus profonde instruction est d'un seul-liner. Donc, mon code ressemble à ceci:
L'autre exception est bien sûr, empilés à l'aide de relevés.
Il n'y a absolument pas de sens dans l'écriture
lorsque vous pouvez écrire
J'aime le plus compact de la mise en forme aussi. C'est pourquoi je suis constamment en appuyant sur Ctrl+K, Ctrl+D pour reformater dans Visual Studio. Je souhaite juste que je pouvais le faire pour moi, après chaque pression de touche.
Parce que StyleCop dit.
Si vous vous sentez "parfois", il est utile d'avoir des accolades, vous devriez retenir d'ajouter des accolades pour être consistante.
Les programmes devraient être écrit pour être lu par des personnes et non à des ordinateurs.
Je préfère des accolades comme:
et non PAS comme
et non pas comme
Sur d'autres de la pensée, si vous êtes en train de supprimer/pas en utilisant des accolades pour enregistrer les lignes, vous avez besoin de refactoriser le code.
Je préfère les accolades dans la plupart des situations. Souvent, vous retrouverez le code pour ajouter plus de lignes de code et vous aurez à ajouter de toute façon.
Il y a beaucoup de bonnes réponses ici au sujet de pourquoi vous ne devriez pas -- et je suis sur le côté qui est d'accord qu'il ne faut pas omettre les accolades.
Si vous êtes à la recherche pour plus laconique code, j'aimerais vraiment travailler avec un ternaire déclaration. Ils fournissent de la compacité avec une certaine quantité de unambiguity et sont plus résistantes aux accidents.
Le problème avec omettre les accolades, comme mentionné, est la probabilité d'erreurs après le fait. La plupart des programmeurs seront d'accord, qu'ils peuvent lire:
Le problème vient quand les gens viennent et modifier l'instruction et ne font pas attention. Au dernier endroit où je travaille, il y a effectivement un problème qui se pose à partir quelqu'un de modifier la déclaration ou de commenter une ligne. Une norme de codage a été mis en place pour s'assurer que des bugs comme ça n'est jamais arrivé encore.
Que quelqu'un d'autre a dit, le temps du programmeur est le coûteux peu. Comme les commentaires de code, il est souvent plus rapide de simplement laisser des morceaux parce qu'ils sont facultatifs, mais facilement maintenable code s'appuie souvent sur les "facultatif" les choses.
Enfin, certaines personnes ont mentionné que des éditeurs modernes et IDEs auto-indentation et de vous montrer l'étendue automatiquement. Ma réponse est de ne pas utiliser de telles choses comme d'une béquille. Il ya des moments où vous êtes en train de regarder le code d'un référentiel source ou via une connexion à distance ou même dans un e-mail, ce sont les réalités du développement. Vous ne pouvez pas avoir une IDE ou un éditeur avancé pour vous montrer ce que vous faites mal. Toujours écrire votre code, de sorte qu'il est facile de comprendre, peu importe ce que vous charge.
Avez-vous pensé à explorer cette option pour une seule ligne si else:
AFAIR accolades sont toujours une portée, donc pour cela il est bon de les utiliser à chaque fois.
Sans les accolades:
Cette compile, mais conduisent à des références nulles facilement. (Compilateur C# ne pas compiler ce, bonne chose!)
Que, de cette façon:
n'aurez même pas compiler.
C'est beaucoup mieux que minize Exceptions à la compile-time déjà, que de trouver lors de l'exécution.