Une seule déclaration si bloc - accolades ou non? [fermé]

Quel est le meilleur / 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 est plus facile de dire ce qui appartient réellement au bloc if, cela évite aux autres d'ajouter plus tard des accolades (ou de créer un bogue en oubliant), et cela rend toutes vos déclarations if uniforme au lieu de certains avec des accolades et certains sans. Le second, toutefois, reste syntaxiquement correct et nettement plus compact. Je suis curieux de voir ce qui est plus généralement préféré par d’autres.

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

if(condition) 
//      statement;
otherStatement;

Ou ajouter du code rapidement:

if(condition) 
    statement;
    otherStatement;

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

if(condition) statement;

Cela réduit le bruit syntaxique tout en donnant l’impression que la construction fait ce qu’elle fait réellement, ce qui la rend moins sujette aux erreurs. À condition que cette syntaxe ne soit utilisée que pour des conditions et des déclarations très simples et brèves, je la trouve parfaitement lisible.

J'utilise toujours des crochets juste pour être en sécurité.

C'est bien quand vous l'écrivez, mais vous savez que quelqu'un viendra dans le futur et insérera une autre déclaration sans la mettre entre crochets.

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

L'explication suivante est longue. S'il vous plaît supporter avec moi. Je vais donner une raison convaincante pour que je préfère ce style. Je vais aussi 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 de fermeture nécessite une ligne de code supplémentaire - ainsi que l'accolade d'ouverture, en fonction du style. ¹

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

Cependant, je déteste gaspiller de l'espace vertical. Les moniteurs modernes ont en fait un grand espace horizontal. Mais l’ espace vertical reste très limité (sauf si vous utilisez un moniteur placé à la verticale, ce qui n’est pas si rare). Cet espace vertical limité est un problème: il est généralement admis 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, ce qui vous permet de 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.

En conséquence, je déteste les lignes vides redondantes. Là où des lignes vides sont essentielles pour délimiter des blocs indépendants (il suffit de regarder l'apparence visuelle de ce texte), les lignes vides consécutives sont un très mauvais style dans mon livre (et, selon mon expérience, elles sont généralement le signe de programmeurs débutants).

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

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

Un seul argument contre les omissions d'accolades consiste à dire que quelqu'un ajoutera ultérieurement une autre instruction au bloc en question et oubliera d'ajouter les accolades, ce qui modifiera par inadvertance la sémantique du code.

Ce serait effectivement un gros problème.

Mais d'après mon expérience, ça ne l'est pas. Je suis un programmeur bâclé; et pourtant, au cours de ma décennie d'expérience en programmation, je peux honnêtement affirmer que je n'ai jamais oublié d'ajouter les accolades lors de l'ajout d'une instruction supplémentaire à un bloc singleton.

Je trouve même invraisemblable que cela soit une erreur commune: les blocs sont un élément fondamental de la programmation. La résolution et la portée des blocs sont un processus mental automatique et enraciné pour les programmeurs. Le cerveau le fait simplement (sinon, raisonner sur la programmation serait beaucoup plus difficile). Aucun effort mental supplémentaire n'est nécessaire pour vous rappeler de mettre les accolades: le programmeur se souvient également d' indenter correctement la déclaration nouvellement ajoutée, après tout; de sorte que le programmeur a déjà traité mentalement qu’un bloc est impliqué.

Maintenant, je ne dis pas qu'omettre des accolades ne cause pas d'erreurs. Ce que je dis, c'est que nous n'avons aucune preuve d'une manière ou d'une autre. Nous ne savons tout simplement pas si cela cause un préjudice.

Donc, tant que personne ne pourra me montrer des données fiables, rassemblées à partir d’expériences scientifiques, démontrant que c’est effectivement un problème, cette théorie reste une « histoire juste pour ainsi dire »: une hypothèse très convaincante qui n’a jamais été mise à l’épreuve, et que ne doit pas être utilisé comme argument.

¹ 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 crois qu'il est prudent de dire que la plupart des gens méprisent cela. De plus, il aurait les mêmes problèmes que la variante sans accolades, donc c'est le pire des deux mondes.

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

J'essaie de ne pas écrire au plus petit dénominateur commun. Je m'attends donc à ce que les autres développeurs sachent écrire l'une des structures de flux de contrôle les plus courantes de la programmation actuelle.

Je voudrais utiliser ce qui suit (le consensus ici):

if (condition) {
    any_number_of_statements;
}

Également possible:

if(condition) single_compact_statement;

Pas très bon, surtout dans les langages de type C / C ++:

if(condition) 
    single_compact_statement;

(Pas de choix ici en Python ;-)

En Perl , vous utiliseriez:

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

ou

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

(Ce n'est pas un pseudocode ;-)

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

Le code fusionne. Il est connu que cela se produit sur des projets sur lesquels j'ai travaillé sur cette déclaration unique si des fusions automatiques ont eu lieu. Ce qui est effrayant, c'est que l'indentation semble correcte même si le code est erroné, ce type de bogue est donc difficile à détecter.

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

Pas d'accolades. Si un autre programmeur ajoute une deuxième déclaration à mon code, ce n’est pas davantage ma faute que si je laissais quelqu'un conduire ma voiture et qu’il franchissait une falaise.

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 sont la lisibilité / la maintenabilité.

Si vous devez ajouter du code au ifbloc, 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.

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

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

Personnellement, je préfère le second. Le premier a l'air moche, maladroit et gaspille de l'espace horizontal. Les principaux problèmes du second problème sont les macros et les personnes modifiant ultérieurement votre code.

Pour cela, je dis "n'utilisez pas de macros". Je dis aussi, "indentez votre fichu code correctement". Considérant que chaque éditeur de texte / IDE utilisé pour la programmation indente automatiquement, cela ne devrait pas être si difficile à faire. Lors de l'écriture de code dans Emacs, j'utiliserais l'indentation automatique pour identifier si j'ai écrit quelque chose de mal sur une ligne précédente. Chaque fois que Emacs commence à bousiller l'indentation, je sais généralement que j'ai commis une erreur.

En pratique, je finis par respecter la convention de codage qui m'a été imposée. Mais ceux-ci m'ennuient (et me rend beaucoup plus heureux lorsque je code en Python et que tout ce désastre entre parenthèses a disparu):

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

ensuite

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

Bien que honnêtement, deux déclarations dans une déclaration if m'ennuient beaucoup plus qu'une seule déclaration. Principalement parce qu'alors des crochets sont nécessaires et que cela semble toujours amusant avec seulement deux déclarations dans la déclaration if.

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 et plus facile à saisir. Je n'utilise ce formulaire que si ces conditions sont remplies; c'est-à-dire que la ifcondition doit correspondre parfaitement à une seule ligne et que l'instruction correspondante doit correspondre parfaitement à la ligne suivante. Si ce n'est pas le cas, j'utiliserai 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 ne contenant qu'une accolade) avant et après la ifdéclaration (ou au-dessus du commentaire, le cas échéant). Bien que ce ne soit pas une règle que je respecte consciemment, je le remarque maintenant après avoir lu cette question.

La conservation de l'espace é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 en même temps pour occuper tout mon écran. S'il y a tellement d'imbrication dans un morceau de code que je ne peux pas comprendre sans en voir plus à la fois, il faudrait que je me demande si la logique pourrait être mieux représentée par la refactorisation.

Vous trouverez ci-dessous quelques exemples illustrant mon utilisation de cette forme d’ ifénoncé.

    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();
    }

Bretelles. Toujours. J'en suis un peu fan, car cela donne une certaine cohérence au code. Et aussi comme @dsimcha l'a écrit - 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 dommageable qu'un travail supplémentaire qui est probable dans les cas de débogage et / ou d'ajout de code.

Personnellement j'y vais avec des crochets.

Pourquoi?

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

Il garde le format des ifdéclarations cohérent quel que soit le nombre de déclarations contenues dans le bloc.

Cependant, si le style du projet doit se passer de rien, tenez-vous-en à cela.

J'utilise presque toujours les crochets juste pour être du bon côté. Cependant, parfois, si le contenu du bloc est vraiment court, je le laisse de côté et le transformera en une ligne comme celle-ci:

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

Je préfère les accolades pour la cohérence, mais je ne gaspille pas trop d’espace blanc (mon code est donc plus lisible que le reste de mon champ de vision). Alors j'écris ceci pour des lignes assez courtes:

If (cond) { statement; }

J'utilise habituellement des accolades, mais dans certains cas, ce n'est pas le cas.

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 idiot de les ajouter ici. Si quelqu'un ajoute une déclaration après le return, nous avons des problèmes plus importants que les problèmes de portée.

Si l'IDE dispose d'un formatage de code, je n'utilise pas d'accolades.

D'autre part, lorsque le code peut être modifié 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 publications. Mais malgré cela, je préfère ne pas utiliser d’accolades, et cela n’a pas posé de problème pour moi.