Quel est le style préféré pour les déclarations de décision et d’action uniques ?

Question

Dans le cas de langages prenant en charge une décision et une action uniques sans crochets, comme l'exemple suivant :

if (var == true)
    doSomething();

Quelle est la manière préférée d’écrire ceci ?Les crochets doivent-ils toujours être utilisés, ou leur utilisation doit-elle rester la préférence de chaque développeur ?De plus, cette pratique dépend-elle de la taille du bloc de code, comme dans l'exemple suivant :

if (var == 1)
    doSomething(1);
else if (var > 1 && var < 10)
    doSomething(2);
else
{
    validate(var);
    doSomething(var);
}

Answer 1

Il n’y a pas vraiment de bonne réponse.C’est à cela que servent les normes de codage au sein de l’entreprise.Si vous parvenez à le maintenir cohérent dans l’ensemble de l’entreprise, il sera facile à lire.personnellement j'aime

if ( a == b)    {
    doSomething();
}
else {
    doSomething();
}

mais c'est une guerre sainte.

Answer 2

je recommande

if(a==b)
{
    doSomething();
}

parce que je trouve beaucoup plus facile de le faire dès le départ que d'essayer de me rappeler d'ajouter les accolades lorsque j'ajoute une deuxième instruction à la condition de réussite...

if(a==b)
    doSomething();
    doSomethingElse();

est très différent de

if(a==b)
{
    doSomething();
    doSomethingElse();
}

voir L'article de Joël pour plus de détails

Answer 3

J'ai tendance à utiliser un appareil dentaire à tout moment.Vous pouvez rencontrer des bugs subtils là où vous avez commencé avec quelque chose comme :

if(something)
 DoOneThing();
else
  DoItDifferently();

puis décidez d'ajouter une autre opération au else clause et oubliez de la mettre entre accolades :

if(something)
 DoOneThing();
else
  DoItDifferently();
  AlwaysGetsCalled(); 

AlwaysGetsCalled() sera toujours appelé, et si vous êtes assis là à 3 heures du matin à vous demander pourquoi votre code se comporte de manière étrange, quelque chose comme ça pourrait vous échapper pendant un certain temps.Pour cette seule raison, j’utilise toujours un appareil dentaire.

Answer 4

Ma préférence est d'être cohérent, par exemple, si vous utilisez des parenthèses sur un bloc, utilisez des parenthèses partout, même avec une seule instruction :

if (cond1)
{
   SomeOperation();
   Another();
}
elseif (cond2)
{
   DoSomething();
}
else
{
   DoNothing();
   DoAnother();
}

Mais si vous n’avez qu’un tas de doublures :

if (cond1)
    DoFirst();
elseif (cond2)
    DoSecond();
else
    DoElse();

Cela a l'air plus propre (si les noms de méthodes factices ne vous dérangent pas ;) de cette façon, mais ce n'est que moi.

Cela s'applique également aux constructions de boucles et autres :

foreach (var s as Something)
    if (s == someCondition)
        yield return SomeMethod(s);

Vous devez également considérer qu'il s'agit d'une convention qui pourrait être plus adaptée à .NET (notez que les utilisateurs de Java aiment avoir leur première accolade sur la même ligne que le if).

Answer 5

Attribuez celui-ci au manque d'expérience, mais au cours de mes sept années en tant que singe codeur, j'ai jamais en fait, j'ai vu quelqu'un faire l'erreur de ne pas ajouter d'accolades lors de l'ajout de code à un bloc qui n'a pas d'accolades.C'est précisément zéro fois.

Et avant que les farfelus n’en parlent, non, la raison n’était pas « tout le monde utilise toujours un appareil dentaire ».

Donc, une question honnête : j'aimerais vraiment obtenir de vraies réponses au lieu de simplement des votes négatifs :est-ce que cela arrive réellement ?

(Modifier:J'ai entendu suffisamment d'histoires d'horreur sur l'externalisation pour clarifier un peu :est-ce que ça arrive réellement à programmeurs compétents?)

Answer 6

Cela n’a pas vraiment d’importance, tant que vous y êtes cohérent.

Il semble y avoir une tendance à exiger la similitude au sein d'une même déclaration, c'est-à-dires'il y a des parenthèses dans une branche, il y en a partout.Les normes de codage du noyau Linux, par exemple, l'exigent.

Answer 7

Je préconiserais fortement toujours en utilisant des accolades, même lorsqu'elles sont facultatives.Pourquoi?Prenez ce morceau de code C++ :

if (var == 1)
  doSomething();
doSomethingElse();

Maintenant, quelqu'un arrive qui n'y prête pas vraiment assez attention et décide que quelque chose de supplémentaire doit se produire si (var == 1), alors il fait ceci :

if (var == 1)
  doSomething();
  doSomethingExtra();
doSomethingElse();

Tout est toujours magnifiquement en retrait, mais cela ne fera pas ce qui était prévu.

En utilisant toujours des accolades, vous aurez plus de chances d'éviter ce genre de bug.

Answer 8

Personnellement, je suis du côté de l'explication de McConnell de Code Complete.

Utilisez-les chaque fois que vous le pouvez.Ils améliorent la lisibilité de votre code et suppriment les rares confusions qui pourraient survenir.

Il y a une chose qui est plus importante cependant… la cohérence.Quel que soit le style que vous utilisez, assurez-vous de toujours le faire de la même manière.

Commencez à écrire des trucs comme :

If A == true
   FunctA();

If B == "Test"
{
   FunctB();
}

Vous finirez forcément par chercher un bug étrange où le compilateur ne comprendra pas ce que vous essayiez de faire et qui sera difficile à trouver.

Fondamentalement, trouvez celui que vous êtes à l’aise d’écrire à chaque fois et respectez-le.Je crois qu'utiliser autant que possible les délimiteurs de blocs ('{', '}') est la voie à suivre.

Je ne veux pas commencer une question par une autre, mais il y a quelque chose en rapport avec cela que je veux mentionner pour stimuler votre esprit.L'une des décisions d'utiliser les supports a été prise.Où place-t-on le support d'ouverture ?Sur la même ligne que la déclaration ou en dessous.Parenthèses en retrait ou pas ?

If A == false {
  //calls and whatnot
}
//or
If B == "BlaBla"
{
  //calls and whatnot
}
//or
If C == B
  {
  //calls and whatnot
  }

S'il vous plaît, ne répondez pas à cela car ce serait une nouvelle question.Si je vois un intérêt à cela, j'ouvrirai une nouvelle question sur votre contribution.

Answer 9

J'ai toujours utilisé des parenthèses à tout moment, sauf dans le cas où je vérifie la valeur NULL d'une variable avant de la libérer, comme c'est nécessaire en C.

Dans ce cas, je m'assure qu'il est clair qu'il s'agit d'une seule instruction en gardant tout sur une seule ligne, comme ceci :

if (aString) free(aString);

Answer 10

Il n’y a pas de bonne ou de mauvaise façon d’écrire la déclaration ci-dessus.Il existe de nombreux codes acceptés modes.Cependant, pour moi, je préfère garder le style de codage cohérent tout au long du projet.c'est à dire.Si le projet utilise le style K&R, vous devez utiliser K&R.

Answer 11

Ruby évite gentiment un problème dans la discussion.La norme pour un one-liner est :

do_something if (a == b)

et pour un multiligne :

if (a == b)
  do_something
  do_something_else
end

Cela permet des instructions concises sur une seule ligne, mais cela vous oblige à réorganiser l'instruction si vous passez d'une seule à plusieurs lignes.

Ce n'est pas (encore) disponible en Java, ni dans de nombreux autres langages, AFAIK.

Answer 12

Comme d'autres l'ont mentionné, faire une instruction if sur deux lignes sans accolades peut prêter à confusion :

if (a == b)
    DoSomething();
    DoSomethingElse(); <-- outside if statement

je le place donc sur une seule ligne si je peux le faire sans nuire à la lisibilité :

if (a == b) DoSomething();

et à tout autre moment, j'utilise un appareil dentaire.

Les opérateurs ternaires sont un peu différents.La plupart du temps, je les fais sur une seule ligne :

var c = (a == b) ? DoSomething() : DoSomethingElse();

Mais parfois, les déclarations ont des appels de fonction imbriqués, ou des expressions de lambda qui rendent une déclaration d'une ligne difficile à analyser visuellement, donc je préfère quelque chose comme ceci:

var c = (a == b)
    ? AReallyReallyLongFunctionName()
    : AnotherReallyReallyLongFunctionOrStatement();

Encore plus concis qu'un bloc if/else mais facile de voir ce qui se passe.

Answer 13

Soleil Conventions de code pour le langage de programmation Java a ce dire:

La classe IF-Else des déclarations devrait avoir le formulaire suivant:

if (condition) {
    statements;
}

if (condition) {
    statements;
} else {
    statements;
}

if (condition) {
    statements;
} else if (condition) {
    statements;
} else {
    statements;
}

Answer 14

Notre patron nous oblige à mettre { } après une déclaration de décision quoi qu'il arrive, même s'il s'agit d'une seule déclaration.C'est vraiment ennuyeux d'ajouter deux lignes supplémentaires.La seule exception concerne les opérateurs ternaires.

Je suppose que c'est une bonne chose que mon moniteur de code soit en orientation portrait à 1200x1600.

Answer 15

je préfère

if (cond)
   {
   //statement
   }

même avec une seule déclaration.Si vous deviez écrire quelque chose une fois, que vous n'aviez aucun doute sur son fonctionnement et que vous n'aviez jamais prévu qu'un autre codeur examine ce code, allez-y et utilisez le format de votre choix.Mais que vous coûte réellement le bracketing supplémentaire ?Moins de temps en un an qu’il n’en faut pour rédiger ce message.

Oui, j'aime aussi mettre mes crochets en retrait au niveau du bloc.

Python est agréable dans la mesure où l'indentation définit le bloc.La question est sans objet dans un langage comme celui-là.

Answer 16

J'ai tendance à être d'accord avec Joel Spolsky sur ce point avec cet article (Donner l'impression qu'un mauvais code est faux) avec l'exemple de code suivant :

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

Foo est désormais inconditionnel.Ce qui est vraiment mauvais !

J'utilise toujours des parenthèses pour les déclarations de décision.Cela facilite la maintenabilité du code et rend le code moins sujet aux bogues.

Answer 17

J'utilise des accolades autour de chaque instruction si et seulement si au moins l'une d'entre elles l'exige.

Answer 18

En Perl, si vous faites un test simple, vous l'écrirez parfois sous cette forme :

do_something if condition;

do_something unless condition;

Ce qui peut être très utile pour vérifier les arguments au début d'un sous-programme.

sub test{
  my($self,@args) = @_;

  return undef unless defined $self;

  # rest of code goes here

}

Answer 19

La règle d'or est que, lorsque vous travaillez sur un projet existant, suivez ces normes de codage.

Quand je suis à la maison, j'ai deux formulaires.

La première est la seule ligne :

if (condition) doThis();

et le second concerne plusieurs lignes :

if (condition) {
   doThis();
}

Answer 20

J'avais l'habitude de suivre la ligne "utilisez toujours des accolades" comme un apparatchik.Cependant, j'ai modifié mon style pour permettre de les omettre sur les expressions conditionnelles sur une seule ligne :

if(!ok)return;

Pour tout scénario multi-instructions, je suis toujours d'avis que les accolades devraient être obligatoires :

if(!ok){

    do();

    that();

    thing();
}