L'utilisation obligatoire des accolades

Question

Dans le cadre d'un document de normes de code que j'ai écrit quelque temps en arrière, je mettre en vigueur « vous devez toujours utiliser des accolades pour les boucles et / ou conditionnel blocs de code, même (surtout) si elles sont qu'une seule ligne. »

Exemple:

// this is wrong
if (foo) 
    //bar
else 
    //baz
while (stuff)
    //things

// This is right.
if (foo) {
    // bar
} else {
    // baz
}
while (things) {
    // stuff
}

Lorsque vous ne préparez-pas une seule ligne, puis quelqu'un qu'il en commentaire, vous êtes en difficulté. Si vous ne préparez-pas une seule ligne, et l'empreinte n'affiche pas la même chose sur la machine de quelqu'un d'autre ... vous êtes en difficulté.

Alors, question: y at-il de bonnes raisons pour lesquelles ce serait une norme erronée ou déraisonnable? Il y a eu des discussions à ce sujet, mais personne ne peut me proposer un meilleur que contre-argument « il se sent laid ».

Answer 1

J'exécuter la présente à un point, à quelques exceptions mineures pour si les déclarations qui évaluent soit revenir ou continuer une boucle.

Alors, cela est correct par ma norme:

if(true) continue;

Comme ce

if(true) return;

Mais la règle est qu'il est soit un retour ou continuer, et il est sur la même ligne. Sinon, pour tout accolades.

Le raisonnement est à la fois dans l'intérêt d'avoir un moyen standard de le faire, et pour éviter le problème des commentaires que vous avez mentionné.

Answer 2

Le meilleur argument contre je peux offrir est que la ligne supplémentaire (s) repris par l'espace réduit la quantité de code que vous pouvez voir à un moment donné, et la quantité de code que vous pouvez voir à un moment donné est un facteur important dans la façon dont il est facile de repérer les erreurs. Je suis d'accord avec les raisons pour lesquelles vous avez donné pour inclure des accolades, mais dans de nombreuses années de C ++ je ne peux penser à une fois quand je fait une erreur en conséquence et il était dans un endroit où je n'avais pas une bonne raison pour sauter les accolades en tous cas. Malheureusement, je ne pourrais pas vous dire si voir ces lignes de code supplémentaires jamais aidé dans la pratique ou non.

Je suis peut-être plus biaisé parce que j'aime la symétrie des accolades correspondant au même niveau d'indentation (et le regroupement implicite des déclarations faites comme un bloc d'exécution) - ce qui signifie que l'ajout des accolades tous le temps ajoute beaucoup de lignes au projet.

Answer 3

Je vois cette règle comme surpuissant. normes draconiens ne font pas de bons programmeurs, ils diminuent les chances que juste un plouc va faire un gâchis.

Les exemples que vous donnez sont valables, mais ils ont de meilleures solutions que de forcer des accolades:

  

Lorsque vous ne préparez-pas une seule ligne, puis quelqu'un qu'il en commentaire, vous êtes en difficulté.

Deux pratiques résoudre ce mieux, en choisir un:

1) Commentaire sur le if, while, etc., avant le revêtement avec une-one-liner. C'est à dire. traiter

if(foo)
    bar();

comme toute autre instruction multi-lignes (par exemple une mission à plusieurs lignes, ou un appel de fonction de plusieurs lignes):

//if(foo)
//    bar();

2) préfixer le // avec un ;:

if(foo)
;//    bar();

  

Si vous ne préparez-pas une seule ligne, et l'empreinte n'affiche pas la même chose sur la machine de quelqu'un d'autre ... vous êtes en difficulté.

Non, vous n'êtes pas; le code fonctionne de la même, mais il est plus difficile à lire. Fixer votre empreinte. Choisissez des onglets ou des espaces et de s'y tenir. Ne pas mélanger les onglets et des espaces pour l'indentation. De nombreux éditeurs de texte corrigera automatiquement pour vous.

Ecrire un code Python. Cela corrigera au moins quelques mauvaises habitudes d'indentation.

En outre, des structures comme } else { ressemblent à une version nethack d'un chasseur TIE pour moi.

  

sont là de bonnes raisons pour lesquelles ce serait une norme erronée ou déraisonnable? Il y a eu des discussions à ce sujet, mais personne ne peut me proposer un meilleur que contre-argument « il se sent laid ».

accolades redondantes (et entre parenthèses) sont l'encombrement visuel. l'encombrement visuel rend plus difficile à lire le code. Le code plus difficile est de lire, plus il est facile de cacher les insectes.

int x = 0;
while(x < 10);
{
    printf("Count: %d\n", ++x);
}

Forcing accolades ne permet pas de trouver le bug dans le code ci-dessus.

P.S. Je suis abonné à la « chaque règle doit dire pourquoi » l'école, ou le Dalaï Lama a dit, « Connaître les règles pour que vous puissiez bien les casser. »

Answer 4

je dois encore avoir quelqu'un est venu avec une bonne raison de ne pas toujours utiliser des accolades.

Les avantages dépassent de loin tout « il se sent laid » raison pour laquelle je l'ai entendu.

Norme de codage pour rendre le code existent plus facile à lire et à réduire les erreurs.

Ceci est une norme qui paie vraiment hors route.

Answer 5

Je trouve difficile d'argumenter avec des normes de codage qui réduisent les erreurs et rendre le code plus lisible. Il peut se sentir laid à certaines personnes au début, mais je pense qu'il est une règle parfaitement valable à mettre en œuvre.

Answer 6

I debout sur le sol qui doit correspondre à bretelles selon l'indentation.

// This is right.
if (foo) 
{
    // bar
}
else 
{
    // baz
}

while (things) 
{
    // stuff
}

En ce qui concerne vos deux exemples, je considère que le vôtre un peu moins lisible depuis trouver les parenthèses de fermeture correspondante peut être difficile, mais plus lisible dans les cas où indentation est incorrecte, alors que la logique permettant d'insérer plus facile. Ce n'est pas une énorme différence.

Même si indentation est incorrect, l'instruction if exécutera la commande suivante, que ce soit sur la ligne suivante ou non. La seule raison de ne pas mettre les deux commandes sur la même ligne est pour le soutien du débogueur.

Answer 7

L'un gros avantage que je vois est qu'il est plus facile d'ajouter des déclarations à conditions et les boucles qui sont contreventés, et il ne prend pas beaucoup de frappes supplémentaires pour créer les accolades au début.

Answer 8

Ma règle personnelle est si elle est un très court « si », puis le mettre sur une seule ligne:

if(!something) doSomethingElse();

En général, j'utiliser seulement quand il y a un tas de ifs comme celui-ci successivement.

if(something == a) doSomething(a);
if(something == b) doSomething(b);
if(something == b) doSomething(c);

Cette situation ne se pose pas très souvent, donc autrement, je toujours utiliser des accolades.

Answer 9

À l'heure actuelle, je travaille avec une équipe qui vit par cette norme, et, alors que je suis résistant à, je respecter pour l'amour de l'uniformité.

Objection pour la même raison pour laquelle j'oppose aux équipes qui interdisent l'utilisation des exceptions ou des modèles ou des macros:. Si vous choisissez d'utiliser une langue, utilisez toute la langue Si les accolades sont optionnelles dans C et C ++ et Java, les rendant obligatoire par convention montre une certaine crainte de la langue elle-même.

Je comprends les risques décrits dans d'autres réponses ici, et je comprends le désir d'uniformité, mais je ne suis pas favorable à subsetting de langue À moins d'une stricte raisons techniques , comme le seul compilateur pour un environnement non accueillant des modèles, ou interaction avec le code C excluant une large utilisation des exceptions.

Une grande partie de ma journée consiste à examiner les changements soumis par les programmeurs juniors, et les problèmes communs qui se posent ont rien à voir avec le placement de croisillon ou des déclarations de liquidation au mauvais endroit. Le risque est surévalué. Je préfère passer mon temps en se concentrant sur plus de problèmes matériels que de chercher des violations de ce que le compilateur heureusement accepter.

Answer 10

La seule façon les normes de codage peut être bien suivi par un groupe de programmeurs est de maintenir le nombre de règles au minimum.

Equilibrer l'avantage par rapport au coût (chaque règle supplémentaire et déconcerte les programmeurs embrouille, et après un certain seuil, réduit effectivement la chance que les programmeurs suivront l'une des règles)

Donc, pour faire une norme de codage:

• Assurez-vous que vous pouvez justifier chaque règle avec une preuve claire qu'il vaut mieux que les alternatives.

• Rechercher des alternatives à la règle - est-il vraiment nécessaire? Si tous vos programmeurs utilisent des espaces (lignes vides et indentation) bien, une instruction if est très facile à lire, et il n'y a aucun moyen que même un programmeur débutant peut tromper une instruction à l'intérieur d'un « si » une déclaration qui est autonome. Si vous obtenez beaucoup de bugs liés à si la portée des travaux, la cause est probablement que vous avez une mauvaise whitepsace / style indentation qui rend le code à lire inutilement difficile.

• Prioriser vos règles par leur effet mesurable sur la qualité du code. Combien de bogues pouvez-vous éviter en appliquant une règle (par exemple, « toujours vérifier null », « toujours valider les paramètres avec une assertion », « toujours écrire un test unitaire » et « toujours ajouter quelques accolades, même si elles ne sont pas nécessaires ») . Les anciennes règles vous permettra d'économiser des milliers de bugs par an. La règle de croisillon peut vous faire économiser un. Peut-être.

• Gardez les règles les plus efficaces, et jeter la balle. Chaff est, au minimum, une règle qui vous coûtera plus cher à mettre en œuvre que tous les bugs qui pourraient survenir en ignorant la règle. Mais sans doute si vous avez plus de 30 règles clés, vos programmeurs ignorent beaucoup d'entre eux, et vos bonnes intentions seront comme la poussière.

• Feu tout programmeur qui commente les bits aléatoires de code sans le lire: -)

P.S. Ma position sur contreventement est: Si le « si » ou le contenu de celui-ci sont à la fois une seule ligne, vous pouvez omettre les accolades. Cela signifie que si vous avez un si contenant un commentaire d'une ligne et une seule ligne de code, le contenu prendre deux lignes, et par conséquent les accolades sont nécessaires. Si la condition if couvre deux lignes (même si le contenu est une seule ligne), alors vous avez besoin des accolades. Cela signifie que vous n'omettez accolades triviaux, simples, lire facilement les cas où les erreurs ne sont jamais faites dans la pratique. (Lorsqu'une instruction est vide, je ne mets pas utiliser des accolades, mais je toujours un commentaire indiquant clairement qu'il est vide, et intentionnellement, mais c'est en bordure d'un autre sujet:. Être explicite dans le code afin que les lecteurs savent que vous vouliez dire une portée à vide plutôt que le téléphone a sonné et vous avez oublié de terminer le code)

Answer 11

De nombreux languanges ont une syntaxe pour une liners comme celle-ci (je pense à Perl en particulier) pour faire face à cette « laideur ». Donc, quelque chose comme:

if (foo)     
//bar
else     
//baz

peut être écrit comme un ternaire en utilisant l'opérateur ternaire:

foo ? bar : baz

et

while (something is true)
{
blah 
}

peut être écrit comme:

blah while(something is true)

Cependant dans les langues qui ne sont pas « sucre » Je certainement placer des accolades. Comme vous l'avez dit empêche les bugs inutiles de ramper et fait l'intention du programmeur plus clair.

Answer 12

Je ne dis pas qu'il est déraisonnable, mais en plus de 15 ans de codage avec les langages C comme, je ne l'ai pas eu un seul problème avec omettant les accolades. Commentant une branche sonne comme un vrai problème en théorie -. J'ai jamais vu qui se passe dans la pratique

Answer 13

Un autre avantage de toujours en utilisant des accolades est qu'il fait de recherche et de remplacement et les opérations automatisées similaires plus facile.

Par exemple: Supposons que je remarque que functionB est généralement appelé immédiatement après functionA, avec un motif similaire d'arguments, et je veux que refactor dupliqué code dans une nouvelle combined_function. Une regex pourrait facilement gérer ce refactoring si vous ne disposez pas d'un outil assez puissant refactoring (de ^\s+functionA.*?;\n\s+functionB.*?;) mais, sans bretelles, une approche simple regex pourrait échouer:

if (x)
  functionA(x);
else
  functionA(y);
functionB();

deviendrait

if (x)
  functionA(x);
else
  combined_function(y);

regexes plus complexes travailleraient dans ce cas particulier, mais je l'ai trouvé très pratique pour pouvoir utiliser les expressions régulières basée sur la recherche et remplacer, un arrêt des scripts Perl et la maintenance automatique de code similaire, donc je préfère un style de codage qui ne fait pas inutilement compliqué.

Answer 14

Je ne crois pas dans votre argument. Personnellement, je ne connais personne qui ait jamais « accidentellement » ajouté une deuxième ligne sous if. Je comprendrais dire que imbriquées déclarations de if devraient avoir des accolades pour éviter un ballants d'autre, mais comme je le vois que vous êtes appliquer un style en raison d'une crainte que, OMI, est mal placée.

Answer 15

Voici les règles non écrites (jusqu'à présent, je suppose), je vais par. Je crois qu'il offre une lisibilité sans sacrifier la justesse. Il est basé sur la croyance que la forme courte est dans un bon nombre de cas, plus lisible que la forme longue.

• Utilisez toujours des accolades si any bloc de l'instruction if/else if/else a plus d'une ligne. Commentaires comptent, ce qui signifie un commentaire partout dans le moyen conditionnel toutes les sections du conditionnel obtenir des accolades.
• En option utiliser des accolades lorsque tous blocs de la déclaration sont exactement une ligne.
• Ne placez jamais l'instruction conditionnelle sur la même ligne que la condition. La ligne après l'instruction if est toujours conditionnelle exécutée.

• Si l'instruction conditionnelle effectue lui-même les mesures nécessaires, le formulaire sera:

  for (init; term; totalCount++)
  {
      // Intentionally left blank
  }
  

Pas besoin de normaliser cette manière verbeux, quand vous pouvez dire ce qui suit:

  

Ne laissez jamais les accolades au détriment de la lisibilité. En cas de doute, choisissez d'utiliser des accolades.

Answer 16

Je pense que la chose importante à propos des accolades est qu'ils expriment très certainement l'intention du programmeur. Vous ne devriez pas avoir à déduire l'intention d'indentation.

Cela dit, j'aime les retours d'une ligne et continue Suggérée par Gus. L'intention est évidente, et il est plus propre et plus facile à lire.

Answer 17

Si vous avez le temps de lire tout cela, alors vous avez le temps d'ajouter des accolades supplémentaires.

Answer 18

Je préfère ajouter des accolades à conditionals une seule ligne pour maintenabilité, mais je peux voir comment le faire sans accolades semble plus propre. Ça ne me dérange pas, mais certaines personnes pourraient être mis hors tension par le bruit visuel supplémentaire.

Je ne peux pas offrir un meilleur argument contraire non plus. Pardon! ;)

Answer 19

Pour des choses comme cela, je recommande simplement venir avec un modèle de configuration pour la autoformatter de votre IDE. Ensuite, chaque fois que vos utilisateurs ont frappé alt-shift-F (ou quel que soit la combinaison de touches est dans votre IDE de choix), les accolades seront automatiquement ajoutés. Ensuite, il suffit de dire que tout le monde: «. Allez-y et changer votre couleur de police, les paramètres PMD ou quoi que S'il vous plaît ne change pas les règles ou indentation automatique contreventement, bien que »

Cela nous profite des outils disponibles pour éviter discuter de quelque chose qui est vraiment pas la peine de l'oxygène qui est normalement consacré.

Answer 20

En fonction langue , ayant des accolades pour une instruction conditionnelle refendu ou instruction de boucle n'est pas obligatoire. En fait, je les enlever pour avoir moins de lignes de code.

C ++:

Version 1:

class InvalidOperation{};

//...
Divide(10, 0);
//...
Divide(int a, in b)
{
   if(b == 0 ) throw InvalidOperation();
   return a/b;
}

Version 2:

class InvalidOperation{};

//...
Divide(10, 0);
//...
Divide(int a, in b)
{
   if(b == 0 )
   { 
      throw InvalidOperation();
   }
   return a/b;
}

C #:

Version 1:

foreach(string s in myList)
   Console.WriteLine(s);

Version2:

foreach(string s in myList)
{
   Console.WriteLine(s);
}

En fonction de votre point de vue, la version 1 ou la version 2 sera plus lisible. La réponse est plutôt subjective .

Answer 21

Wow. PERSONNE NE est au courant de la ballants problème d'autre? Ceci est essentiellement LA raison de toujours en utilisant des accolades.

En un mot, vous pouvez avoir une logique ambiguë méchant avec les déclarations d'autre, surtout quand ils sont imbriqués. Différents compilateurs résoudre l'ambiguïté de leurs propres moyens. Il peut être un énorme problème pour laisser hors accolades si vous ne savez pas ce que vous faites.

Esthétique et lisibilité n'a rien à faire.