Formatage des instructions if

Question

Ce n'est pas une guerre sainte, ce n'est pas une question de "quel est le meilleur".

Quels sont les avantages d'utiliser le format suivant pour une instruction unique en cas de blocage?

if (x) print "x is true";

if(x) 
    print "x is true";

Par opposition à

if (x) { print "x is true"; }
if(x) {
    print "x is true";    
}

Si vous formatez votre déclaration unique sans crochets ou si vous connaissez un programmeur qui le sait, qu'est-ce qui vous a amené à adopter ce style en premier lieu? Je suis particulièrement intéressé par les avantages que cela vous a apporté.

Mise à jour : étant donné que la réponse la plus populaire ignore la question (même si elle présente le conseil le plus sain d’esprit), voici un aperçu des avantages sans parenthèses.

1. Compacité
2. Plus lisible par certains
3. Les crochets appellent scope, ce qui entraîne parfois une surcharge théorique

Answer 1

Je trouve ceci:

if( true ) {
    DoSomething();
} else {
    DoSomethingElse();
}

mieux que cela:

if( true )
    DoSomething();
else
    DoSomethingElse();

Ainsi, si moi-même (ou quelqu'un d'autre) revenais plus tard dans ce code pour ajouter plus de code à l'une des branches, je n'aurais pas à craindre d'oublier de placer le code entre accolades. Nos yeux verront visuellement l'indentation comme un indice de ce que nous essayons de faire, mais pas la plupart des langues.

Answer 2

Je n'aime pas beaucoup les styles qui placent le test et le corps du if sur la même ligne.

En effet, le partage de la ligne rend impossible la définition d'un point d'arrêt sur le corps de l'i dans de nombreux débogueurs, car les points d'arrêt sont généralement basés sur le numéro de ligne.

Answer 3

Toujours utiliser des accolades est une bonne idée, mais la réponse standard toujours donnée est que "si quelqu'un ajoute une ligne de code et oublie d’ajouter les accolades?" est une raison plutôt faible.

Il existe un bogue subtil qui peut être introduit en n’ayant pas les accolades au début. Cela m'est arrivé plusieurs fois et je l'ai déjà vu arriver à d'autres programmeurs.

Cela commence, assez innocemment, avec une simple déclaration if.

if (condition)
    do_something();
else
    do_something_else();

Ce qui est très bien.

Ensuite, quelqu'un arrive et ajoute une autre condition au if. Ils ne peuvent pas l'ajouter avec & amp; & amp; à l'instruction if elle-même, car la logique serait incorrecte, ils ajoutent donc un autre si. Nous avons maintenant:

if (condition)
    if (condition2)
        do_something();
else
    do_something_else();

Voyez-vous le problème? Cela peut sembler correct mais le compilateur voit les choses différemment. Il le voit comme ça:

if (condition)
    if (condition2)
        do_something();
    else
        do_something_else();

Ce qui signifie quelque chose de complètement différent. Le compilateur ne se soucie pas de la mise en forme. Le reste va avec le plus proche si. Les humains, quant à eux, dépendent du formatage et peuvent facilement passer à côté du problème.

Answer 4

j'utilise toujours

if(x) 
{
    print "x is true";    
}

Si vous omettez les accolades, le maintien du code peut être erroné, car il pense qu'il est en train d'ajouter à la clause if s'il ajoute une ligne après la ligne en cours.

Answer 5

J'utilise

if (x)
{
    DoSomething();
}

pour plusieurs lignes, mais je préfère les doublures sans support:

if (x)
   DoSomething();
else
   DoSomethingElse();

Je trouve les parenthèses superflues visuellement offensantes, et je ne me suis jamais rendu l’une des erreurs susmentionnées n’ajoutant pas de crochets lors de l’ajout d’une autre déclaration.

Answer 6

if
{
// code
}
else 
{
// else code
}

parce que j'aime bien quand les blocs de code s'alignent (y compris leurs accolades).

Answer 7

Si je code:

if(x) 
    print "x is true";

et 6 mois plus tard, il faut ajouter une nouvelle ligne. La présence d'accolades rend beaucoup moins probable que je tape

if(x) 
    print "x is true";
    print "x is still true";

ce qui entraînerait une erreur logique, par opposition à:

if(x) { 
    print "x is true";
    print "x is still true";
}

Je trouve donc que les accolades rendent ces erreurs logiques plus faciles à lire et à éviter.

Answer 8

Comme Matt (3 ci-dessus), je préfère:

if (x)
{
    ...statement1
    ...statement2
}

et

if (x)
    ...statement
else
    ...statement

Je pense qu'il est assez étrange de penser que quelqu'un puisse arriver plus tard et ne PAS se rendre compte qu'il doit ajouter des accolades pour former une ligne multiple en cas de blocage. Si cela dépasse leurs capacités, je me demande quelles sont les autres choses!

Answer 9

Une seule déclaration si les blocs sont sans accolades:

Avantages:

• moins de caractères
• look plus propre

Inconvénients:

• uniformité: pas tous si les blocs se ressemblent
• possibilité de bogues lors de l'ajout d'instructions au bloc: un utilisateur peut oublier d'ajouter des accolades et la nouvelle instruction ne serait pas couverte par le if.

  

Comme dans:

if(x) 
    print "x is true";
    print "something else";

Answer 10

J'ai tendance à n'utiliser qu'une seule ligne lorsque je teste les conditions de rupture au début d'une fonction, car j'aime garder ce code aussi simple et dégagé que possible

public void MyFunction(object param)
{
     if (param == null) return;

     ...
}

De plus, si je veux éviter les accolades et le code de clause if en ligne, je peux les mettre en ligne, afin que tous ceux qui ajoutent de nouvelles lignes à la liste le voient si

doit être ajouté. >

Answer 11

j'utilise

if (cond) {
  ...
} else {
  ...
}

• Tout doit toujours avoir des accolades. Même si maintenant je n’ai plus qu’une ligne dans le bloc if, j’en ai rajouté plus tard.
• Je ne mets pas les accolades sur leurs propres lignes car c'est une perte d'espace inutile.
• Je mets rarement le bloc sur la même ligne que le conditionnel pour la lisibilité.

Answer 12

Joel Spolsky a écrit un bon article: Rendre le code erroné et incorrect

Il aborde spécifiquement ce problème & # 8230;

if (i != 0)  
    foo(i);

     

Dans ce cas, le code est correct à 100%;   il est conforme à la plupart des conventions de codage   et il n’ya rien de mal à cela, mais   le fait que la déclaration unique   le corps de l'indication n'est pas   enfermés dans des accolades peut vous déranger,   parce que vous pensez peut-être dans le   derrière ta tête, ça alors, quelqu'un   pourrait insérer une autre ligne de code   il

if (i != 0)
    bar(i);
    foo(i);

     

& # 8230; et oubliez d'ajouter les accolades, et   donc faire accidentellement   foo (i) inconditionnel! Alors quand tu vois   des blocs de code qui ne sont pas entre accolades,   vous pourriez sentir juste un petit, petit,   soupe de malpropreté qui fait   vous êtes inquiet.

Il suggère que vous & # 8230;

  

& # 8230; délibérément architecte votre code   de telle sorte que votre nez pour   la malpropreté rend votre code plus   susceptible d'être correct.

Answer 13

Je n'aime pas utiliser des accolades quand elles ne sont pas nécessaires. J'ai l'impression que cela gonfle le nombre de lignes d'une méthode et la rend illisible. Donc, je vais presque toujours pour ce qui suit:

if (x)
   print "x is true"
for (int i=0; i<10; i++)
   print "y is true"

Et ainsi de suite. Si quelqu'un a besoin d'ajouter une autre déclaration, il peut simplement ajouter les accolades. Même si vous n’avez pas R # ou quelque chose de similaire, c’est une très petite affaire.

Néanmoins, dans certains cas, j’utiliserais des accolades même s’il n’y avait qu’une ligne dans la déclaration, c’est-à-dire si la ligne est particulièrement longue ou si j’ai besoin de commentaires à l’intérieur du «si». En gros, j’utilise tout ce qui me semble plus agréable à regarder.

Answer 14

Whitespace est votre ami ....

mais, encore une fois, j'aime bien:

if (foo)
{
    Console.WriteLine("Foobar");
}

Answer 15

Sérieusement, quand est la dernière fois que vous avez eu un bogue dans un code qui soit parce que quelqu'un le faisait:

if (a)
  foo();
  bar();

Oui, jamais ... * Le seul vrai "pro" est de faire correspondre le style du code environnant et de laisser les batailles esthétiques aux enfants qui viennent de sortir du collège.

* (l'avertissement étant que foo (); bar (); était un développement de macro, mais c'est un problème avec les macros, pas les accolades w / ifs.)

Answer 16

if (x) {
    print "x is true";    
}
else {
    do something else;
}

Je tape toujours des accolades. C'est juste une bonne habitude. Par rapport à la pensée, taper n’est pas un "travail".

Notez l'espace avant le conditionnel. Cela aide à ne pas ressembler à un appel de méthode.

Answer 17

Une autre façon serait d'écrire:

(a==b) ? printf("yup true") : printf("nop false");

Cela sera pratique si vous souhaitez stocker une valeur comparant une condition simple, comme ceci:

int x = (a==b) ? printf("yup true") : printf("nop false");

Answer 18

if (x)
{
    print "x is true";
}

L'ouverture et la fermeture d'une accolade dans la même colonne facilite la recherche d'accolades incompatibles et isole visuellement le bloc. Accolade d’ouverture dans la même colonne que "if" il est facile de voir que le bloc fait partie d’un conditionnel. L'espace blanc supplémentaire autour du bloc créé par les lignes contenant uniquement des accolades facilite la sélection de la structure logique lors de la lecture rapide de code. Toujours utiliser explicitement les accolades aide à éviter les problèmes lorsque les personnes modifient le code plus tard et à interpréter de manière erronée les instructions qui font partie du conditionnel et celles qui ne le sont pas.

Answer 19

Le seul moment où aucun renforcement ne semble être accepté est lorsque le paramètre vérifiant les variables au début d'une méthode:

public int IndexOf(string haystack, string needle)
{
    // check parameters.
    if (haystack == null)
        throw new ArgumentNullException("haystack");
    if (string.IsNullOrEmpty(needle))
        return -1;

    // rest of method here ...

Le seul avantage est la compacité. Le programmeur n'a pas à parcourir des {} inutiles lorsqu'il est évident que:

• la méthode se termine sur n'importe quelle branche vraie
• il est assez évident que ce sont tous des 1-liners

Cela dit, je voudrais toujours {} pour la logique du programme pour les raisons indiquées par d'autres. Lorsque vous laissez tomber les accolades, il est trop facile de s'y atteler mentalement quand ce n'est pas là et d'introduire des défauts de code subtils.

Answer 20

H8ers soit damné je ne suis pas vraiment un pour les règles dogmatiques. Dans certaines situations, je privilégierai la compacité si elle ne dépasse pas une certaine largeur, par exemple:

if(x > y)      { xIsGreaterThanY(); }
else if(y > x) { yIsGreaterThanX; }
else           { xEqualsY(); }

C’est beaucoup plus lisible que:

if( x > y ){
    xIsGreaterThanY(); 
}else if( x < y){
    yIsGreaterThanX();
}else{
    xEqualsY();
}

Cela présente l’avantage supplémentaire d’encourager les gens à faire de la logique abstraite dans des méthodes (comme je l’ai fait) plutôt que de continuer à mettre plus de logique dans des blocs imbriqués if-else. Il prend également trois lignes au lieu de sept, ce qui pourrait permettre de ne pas avoir à faire défiler l'écran pour voir plusieurs méthodes ou un autre code.

Answer 21

Je préfère le style entre crochets, principalement parce que cela donne aux yeux un point de départ et d’arrêt clair. Il est plus facile de voir ce qui est réellement contenu dans la déclaration et qu’il s’agit bien d’une déclaration if. Une petite chose, peut-être, mais c'est pourquoi je l'utilise.

Answer 22

tant qu'il est cohérent parmi l'équipe dans laquelle vous travaillez, cela n'a pas d'importance tant que vous

que tout le monde fasse la même chose est la chose principale

Answer 23

Mettez entre parenthèses vos phrases uniques si vous avez le bon sens de vous protéger des maux de tête si, à un moment ultérieur, vous (ou d’autres codeurs conservant ou modifiant votre code) devez ajouter des instructions à une partie de cette condition. bloquer.

Answer 24

Si vous faites quelque chose comme ça:

if(x)
{
    somecode;
}
else
{
    morecode;
}

Cela fonctionne mieux pour les directives de contrôle de source et de préprocesseur sur un code qui vit longtemps. Il est plus facile d'ajouter un #if ou si sans rompre la déclaration par inadvertance ou avoir à ajouter des lignes supplémentaires.

c’est un peu étrange de s’y habituer, mais ça marche assez bien après une pendant que.

Answer 25

Si c'est une ligne de if (et éventuellement une ligne de else), je préfère ne pas utiliser les crochets. C'est plus lisible et concis. Je dis que je le préfère parce que c'est purement une question de préférence. Bien que je pense qu'essayer d'appliquer une norme que vous devez toujours utiliser les accolades est un peu ridicule.

Si vous devez vous inquiéter du fait que quelqu'un ajoute une autre ligne au corps de l'instruction if sans ajouter les accolades (alors seulement obligatoires), je pense que vous avez des problèmes plus importants que les normes de codage sous-byzantin.

Answer 26

/* I type one liners with brackets like this */
if(0){return(0);}
/* If else blocks like this */
if(0){
    return(0);
}else{
    return(-1);
}

Je n'utilise jamais d'espaces superflus au-delà des onglets, mais l'inclusion des crochets économise un temps fou.

Answer 27

Je n'aime pas fermer les accolades sur la même ligne avec le mot clé suivant:

if (x) {
    print "x is true";    
} else {
    do something else;
}

Cela rend plus difficile de supprimer / commenter uniquement la clause else. En mettant le mot clé Follow sur la ligne suivante, je peux tirer parti, par exemple, des éditeurs qui me permettent de sélectionner une plage de lignes et de les commenter / décommenter en même temps.

if (x) {
    print "x is true";    
}
//else {
//    do something else;
//}

Answer 28

Je préfère toujours ceci:

if (x) doSomething();

if (x) {
    doSomthing();
    doOtherthing();
}

Mais dépendez toujours de la langue et des actions que vous faites. Parfois, j'aime mettre des bretelles et parfois non. Comptez sur le code, mais je code comme si je devais écrire une fois, réécrire dix fois et lire cent fois; alors, faites-le comme vous voulez et comme vous voulez lire et comprendre plus rapidement

Answer 29

Quoi qu’il en soit, c’est comme ça que je vais! Il a l'air le meilleur.

If(x)
{
    print "Hello World !!"
}
Else
{
    print "Good bye!!"
}

Answer 30

Si vous souhaitez connaître les noms des différents styles de formatage du code, Wikipedia a publié un article sur Styles d'indentation .