it-swarm.dev

Instruction unique si bloc - accolades ou non?

Qu'est-ce qui est mieux/plus généralement accepté?

Cette:

if(condition)
{
  statement;
}

Ou:

if(condition)
  statement;

J'ai tendance à préférer le premier, car je pense qu'il permet de dire plus facilement ce qui appartient réellement au bloc if, il évite aux autres d'ajouter les accolades plus tard (ou de créer un bogue en oubliant de), et cela rend toutes vos instructions if uniforme au lieu de certains avec bretelles et certains sans. Le second, cependant, est toujours syntaxiquement correct et nettement plus compact. Je suis curieux de voir ce qui est plus généralement préféré par d'autres.

59
Zann Anderson

Le premier est meilleur car le second est sujet aux erreurs. Par exemple, supposons que vous commentez temporairement du code pour déboguer quelque chose:

if(condition) 
//      statement;
otherStatement;

Ou ajouter du code à la hâte:

if(condition) 
    statement;
    otherStatement;

C'est évidemment mauvais. D'un autre côté, le premier semble parfois trop verbeux. Par conséquent, je préfère tout mettre sur une seule ligne si elle est suffisamment courte et simple:

if(condition) statement;

Cela réduit le bruit syntaxique tout en faisant ressembler la construction à ce qu'elle fait réellement, ce qui la rend moins sujette aux erreurs. Pourvu que cette syntaxe ne soit utilisée que pour des conditions et des instructions très simples et courtes, je la trouve parfaitement lisible.

131
dsimcha

J'utilise toujours des parenthèses juste pour être sûr.

C'est bien quand vous l'écrivez, mais vous savez que quelqu'un viendra à l'avenir et insérera une autre déclaration sans mettre de crochets autour.

44
Neil Aitken

Je préfère la version sans accolades dans la mesure du possible.

L'explication suivante est longue. S'il vous plaît, supportez-moi. Je vais vous donner une raison impérieuse de préférer ce style. Je vais également expliquer pourquoi je pense que le contre-argument habituel ne tient pas.

Les lignes (presque) vides sont un gaspillage

La raison en est que l'accolade fermante nécessite une ligne de code supplémentaire - tout comme l'accolade ouvrante, selon le style.1

Est-ce un gros problème? Superficiellement, non. Après tout, la plupart des gens mettent également des lignes vides dans leur code pour séparer les blocs logiquement légèrement indépendants, ce qui améliore considérablement la lisibilité.

Cependant, je déteste gaspiller l'espace vertical. Les moniteurs modernes ont en fait un grand espace horizontal. Mais vertical l'espace est toujours très, très limité (à moins que vous n'utilisiez un moniteur redressé, ce qui n'est pas si rare). Cet espace vertical limité est un problème: il est largement reconnu que les méthodes individuelles doivent être aussi courtes que possible et que les accolades correspondantes (ou d'autres délimiteurs de bloc) ne doivent pas être plus d'une hauteur d'écran différente afin que vous puissiez voir le bloc entier sans défilement.

C'est un problème fondamental: une fois que vous ne pouvez plus voir le bloc entier sur votre écran, il devient compliqué à saisir.

Par conséquent, je déteste les lignes vides redondantes. Lorsque des lignes vides simples sont cruciales pour délimiter des blocs indépendants (il suffit de regarder l'apparence visuelle de ce texte), consécutif les lignes vides sont un très mauvais style dans mon livre (et d'après mon expérience, ils sont généralement un signe de programmeurs novices).

De même, les lignes qui tiennent simplement une accolade et qui pourraient être économisées devraient l'être. Un bloc à instruction unique qui est délimité par des accolades gaspille une à deux lignes. Avec seulement 50 lignes par hauteur d'écran, cela se remarque.

Omettre les accolades ne fait peut-être pas de mal

Il y a juste un argument contre l'omission d'accolades: que quelqu'un ajoutera plus tard une autre instruction au bloc en question et oubliera d'ajouter les accolades, changeant ainsi par inadvertance la sémantique du code.

Ce serait en effet un gros problème.

Mais d'après mon expérience, ce n'est pas le cas. Je suis un programmeur bâclé; et pourtant, dans ma décennie d'expérience en programmation, je peux honnêtement dire que j'ai pas une seule fois oublié d'ajouter les accolades lors de l'ajout d'une instruction supplémentaire à un bloc singleton.

Je trouve même peu plausible que ce soit une erreur courante: les blocs sont une partie fondamentale de la programmation. La résolution et la portée au niveau des blocs sont un processus mental automatique et enraciné pour les programmeurs. Le cerveau le fait (sinon, raisonner sur la programmation serait beaucoup plus difficile). Il n'y a aucun effort mental supplémentaire requis pour se rappeler de mettre les accolades: le programmeur se souvient également de indentation la déclaration nouvellement ajoutée correctement, après tout; donc le programmeur a déjà mentalement traité qu'un bloc est impliqué.

Maintenant, je dis pas disant que l'omission d'accolades ne cause pas d'erreurs. Ce que je dis c'est que nous n'avons aucune preuve dans un sens ou dans l'autre. Nous avons simplement ne sais pas si cela cause du tort.

Donc, jusqu'à ce que quelqu'un puisse me montrer des données solides, collectées à partir d'expériences scientifiques, démontrant que c'est effectivement un problème dans la pratique, cette théorie reste une " histoire juste ": une hypothèse très convaincante qui n'a jamais été mis à l'épreuve, et qui doit pas être utilisé comme argument.


1 Ce problème est parfois résolu en mettant tout - y compris les accolades - sur la même ligne:

if (condition)
{ do_something(); }

Cependant, je pense qu’il est prudent de dire que la plupart des gens le méprisent. De plus, il aurait les mêmes problèmes que la variante sans croisillons, donc c'est le pire des deux mondes.

27
Konrad Rudolph

Je pars avec le second. C'est plus succinct et moins verbeux.

J'essaie de ne pas écrire dans le plus petit dénominateur commun, donc je m'attends à ce que les autres développeurs sachent écrire l'une des structures de flux de contrôle les plus courantes en programmation aujourd'hui.

19
Steven Evers

J'utiliserais ce qui suit (le consensus ici):

if (condition) {
    any_number_of_statements;
}

Également possible:

if(condition) single_compact_statement;

Pas si bon, surtout dans les langages similaires à C/C++:

if(condition) 
    single_compact_statement;

(Pas de choix ici en Python ;-)


Dans Perl , vous utiliseriez:

$C = $A**3 if $A != $B;

ou

$C = $A**3 unless $A == $B;

(Ce n'est pas pseudocode ;-)

16
rubber boots

J'utilise la méthode des accolades - pour toutes les raisons ci-dessus et une de plus.

Le code fusionne. Il est connu que cela se produit sur des projets sur lesquels j'ai travaillé et qui ont été interrompus par des fusions automatiques. La chose effrayante est l'indentation semble correcte même si le code est incorrect, donc ce type de bogue est difficile à repérer.

Je vais donc avec des accolades - sur leurs propres lignes. Il est plus facile de repérer les niveaux de cette façon. Oui, cela gaspille des biens immobiliers à écran vertical et c'est un véritable inconvénient. Tout compte fait, je pense que cela en vaut la peine.

11
user36294

Aucun appareil dentaire. Si un autre programmeur ajoute une deuxième déclaration à mon code, ce n'est pas plus ma faute que si je laisse quelqu'un conduire ma voiture et qu'il passe sur une falaise.

10
Covar

Nous avons eu cet argument plus d'une fois ici, et le consensus général est de toujours utiliser des accolades. Les principales raisons concernent la lisibilité/maintenabilité.

Si vous devez ajouter du code au bloc if, vous n'avez pas besoin de vous souvenir/rechercher des accolades. Lorsque les futurs programmeurs lisent le code, les accolades sont toujours sans ambiguïté.

Du côté positif, ReSharper ajoutera automatiquement les accolades pour les programmeurs paresseux dans Visual Studio, et je suppose qu'il existe des addons pour d'autres IDE qui le feront également.

8
shimonyk

J'utilise la première syntaxe, presque sans exception. Parce que il ne peut pas être mal interprété.

"Ne me faites pas penser" ne s'applique pas seulement aux interfaces utilisateur, vous tous ;-)

7
Steven A. Lowe

Personnellement, je préfère le second. Le premier semble laid, maladroit et gaspille l'espace horizontal. Les principaux problèmes avec le second sont les macros et les personnes qui modifient votre code à un moment ultérieur se trompent.

Pour cela, je dis "ne pas utiliser de macros". Je dis aussi "indentez correctement votre fichu code". Compte tenu de la façon dont chaque éditeur de texte/IDE utilisé pour la programmation indentation automatiquement, cela ne devrait pas être si difficile à faire. Lors de l'écriture de code dans Emacs, j'utilisais l'indentation automatique pour identifier si j'avais écrit quelque chose de mal sur une ligne précédente. Chaque fois qu'Emacs commence à bousiller l'indentation, je sais généralement que j'ai fait quelque chose de mal.

Dans la pratique, je finis par suivre la convention de codage qui m'a été fixée. Mais ceux-ci m'ennuient (et me rendent beaucoup plus heureux quand je code en Python et toute cette catastrophe de support est partie):

if (condition) {
    statement;
} // stupid extra brace looks ugly

Alors

if (condition) // the brackets have now just become noise
{ statement; } // also can't see the indentation, harder to read

Bien honnêtement, deux déclarations dans une déclaration if m'ennuient beaucoup plus qu'une seule déclaration. Surtout parce qu'alors des crochets sont requis et cela a toujours l'air drôle avec seulement deux instructions dans l'instruction if.

5
jsternberg

J'utilise la version à deux lignes sans accolades (la 2ème forme), mais pas pour économiser de l'espace.

J'utilise ce formulaire parce que je le trouve plus lisible, plus attrayant visuellement et plus facile à taper. J'utilise ce formulaire uniquement si ces conditions sont remplies; c'est-à-dire que la condition if doit bien tenir sur une seule ligne, et l'instruction correspondante doit bien tenir sur la ligne suivante. Si ce n'est pas le cas, je vais utiliser des accolades pour améliorer la lisibilité.

Si j'utilise ce formulaire, je m'assure qu'il y a une ligne vide (ou une ligne contenant uniquement une accolade) avant et après l'instruction if (ou au-dessus du commentaire, si présent). Bien que ce ne soit pas une règle que je suive consciemment, je le remarque maintenant après avoir lu cette question.

La conservation de l'espace d'écran n'est pas une priorité pour moi. Si j'avais besoin de plus d'espace, j'utiliserais un moniteur plus grand. Mon écran est déjà suffisamment grand pour que je puisse lire tout ce sur quoi je pourrais avoir besoin de concentrer mon attention. Il est peu probable que je doive me concentrer sur autant de lignes de code à la fois qu'elles occupent tout mon écran. S'il y a tellement d'imbrication en cours avec un morceau de code que je ne peux pas le comprendre sans en voir plus à la fois, alors je devrais déterminer si la logique pourrait être mieux représentée par le refactoring.

Voici quelques exemples qui montrent comment j'utilise cette forme de l'instruction if.

    string GuardConditions(Plan planForWorldDomination)
    {
        if (planForWorldDomination == null)
            throw new ArgumentNullException("planForWorldDomination");

        if (!planForWorldDomination.IsComplete())
            return "Doh!";

        planForWorldDomination.Execute();
    }

    void ProcessingLogic()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
        OneBlankLineAbove();

        // optional comment on the line above an if statement
        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
    }

    void Assignment(string drive)
    {
        OneBlankLineAbove();

        string Prompt;
        if (simpleCondition)
            Prompt = "simple assignment";
        else
            Prompt = null;

        OneBlankLineBelow();
    }

    string Return()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            return "simple return";
        else
            return null;

        OneBlankLineBelow();
    }
4

Un appareil dentaire. Toujours. Je suis un peu fan d'eux, car cela donne au code une certaine cohérence. Et aussi, comme l'a écrit @dsimcha - moins de risques d'erreurs lors de l'ajout de lignes de code supplémentaires.

La "laideur" des accolades autour d'une seule ligne de code est moins nuisible que le travail supplémentaire qui est probable dans ces cas avec le débogage et/ou l'ajout de code.

3

Personnellement, je vais avec des crochets.

Pourquoi?

Eh bien, si quelqu'un arrive et doit ajouter du code dans l'instruction if, il est clair à 100% où se trouve la portée.

Il maintient le format des instructions if cohérent quel que soit le nombre d'instructions dans le bloc.

Cependant, si le style du projet doit disparaître, respectez-le.

2
ChrisF

J'utilise presque toujours les supports juste pour être du bon côté. Cependant, parfois, si le contenu du bloc est vraiment court, je les laisse de côté et j'en fais une doublure comme ceci:

if (x==5) Console.WriteLine("It's a five!");
1
JohnFx

Je préfère les accolades pour la cohérence, mais sans perdre trop d'espace blanc (donc le code formaté de manière plus lisible est dans mon champ de vision limité). J'écris donc ceci pour des lignes assez courtes:

If (cond) { statement; }
1
hotpaw2

J'utilise habituellement des accolades, mais il y a des cas où je ne le fais pas.

object GetObject() {
    // calculate obj1
    if(obj1 != null)
        return obj1;

    // calculate obj2
    if(obj2 != null)
        return obj2;

    // calculate obj3
    if(obj3 != null)
        return obj3;

    return defaultObj;
}

Pour moi, il serait tout simplement idiot de les ajouter là-bas. Si quelqu'un ajoute une instruction après le return, nous avons de plus gros problèmes que les problèmes de portée.

Si le IDE a un formatage de code disponible, je n'utilise pas d'accolades.

D'un autre côté, lorsque le code peut être édité dans d'autres éditeurs qui ne prennent pas en charge le formatage automatique, il est dangereux de ne pas mettre d'accolades comme mentionné dans d'autres articles. Mais même ainsi, je préfère ne pas utiliser d'appareils orthopédiques, et cela n'a pas été un problème pour moi.

0
nimcap