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


59

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.


2
Mais vous avez votre porte d’ouverture dans la mauvaise position. C'est certain.
Christian Mann

Dans de nombreuses langues, un bloc est une instruction. Par conséquent, syntaxiquement, c'est toujours une instruction (expression)
Ingo

2
Puisque vous ne spécifiez pas une langue ... Qu'en est- il statement if condition;?
Dave Sherohman

@Christian - bon. Ce serait une autre question distincte de celle-ci, non?
Zannjaminderson le

@Ingo - bon point.
Zannjaminderson le

Réponses:


131

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.


35
Bon point de tout mettre sur une seule ligne.
Neil Aitken

7
@artjomka: Si l'instruction est longue et doit suivre sa propre ligne, j'utilise des accolades pour améliorer la lisibilité. Le fait est que vous voulez la construction la plus courte, la moins bruyante du point de vue syntaxique, qui soit sans ambiguïté pour un humain qui la lit rapidement plutôt que de la scruter.
Dsimcha

15
Je préfère celui avec des accolades pour les raisons déjà mentionnées. Je n'aime pas le one-liner, car il n'est pas immédiatement évident de savoir ce qui se passe lorsque je franchis la ligne du débogueur. Je dois prendre une mesure séparée pour voir quelle condition est évaluée.
Jim Un

10
@TMN Les espaces sont gratuits, les moniteurs sont grands et votre cerveau apprend à reconnaître la forme qui vous aide à analyser le code.
Murph

5
@Murph: les espaces sont gratuits? J'ai dû manquer ça. Sur mon écran, cela prend vraiment beaucoup de place. Beaucoup plus que 50% en fait. Ce qui dans mon livre semble être un gros gaspillage. Personnellement, j'aime maximiser le contenu par centimètre carré dans le code.
Konrad Rudolph

44

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.


20
Les gens ont-ils vraiment vu cela arriver? Je ne pense pas avoir déjà vu cela en 10 ans de programmation. Peut-être que je viens d'être trop à l'abri. :)
David

9
J'adorerais dire non, mais malheureusement, je l'ai vu.
Neil Aitken

13
Vous utilisez toujours des crochets pour ne jamais oublier d'utiliser des crochets - c'est aussi simple que cela.
Murph

12
+1 à @Murph. Même raison, j'utilise mes clignotants quand il n'y a personne - et dans les parkings!
Dan Ray

7
C'est une bonne pratique pour éviter les erreurs lors de la fusion d'une branche à une autre ou entre plusieurs branches.
JBRWilkinson

27

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. 1

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.


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 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.


6
Omettre les accolades nuit à la lisibilité et peut facilement causer des problèmes lorsque le code est modifié.
Josh K

15
@ Josh: la première affirmation est ridicule, comme le montrent des langages tels que Python (apportez des preuves si vous pensez le contraire). Le second a été contré dans ma réponse. Avez-vous des preuves pour le sauvegarder? Sinon, votre commentaire indique que vous n’avez pas lu mon texte. Merci de le faire avant de le critiquer.
Konrad Rudolph

8
+1 pour vos pensées, mais je pense que votre position est contre-productive. Vous dites "montrez-moi des données concrètes, recueillies à partir d'expériences scientifiques, montrant qu'il s'agit bien d'un problème dans la pratique" et reposez-vous sur une expérience anecdotique (la vôtre) pour défendre votre position. Vous dites "dans mon expérience ... dans ma décennie d'expérience ... je trouve cela invraisemblable ..." et ainsi de suite. Pouvez-vous montrer des données concrètes, recueillies d'expériences scientifiques, à l'appui de votre affirmation, "L'omission d'accolades ne nuit pas"? Une expérience personnelle est acceptable pour appuyer une opinion, mais ne demandez pas plus de "preuves" que ce que vous êtes disposé à donner.
bedwyr

3
@bedwyr: il y a cependant une différence qualitative. Premièrement, je précise que les données me persuaderont, mais je précise également que la mienne n’est qu’une hypothèse, non étayée par des données. Deuxièmement, j’ai énoncé un argument (du moins pour moi) plausible à l’origine de ma conviction que l’affirmation est fausse et pourquoi elle doit être corroborée. Ce qui m'amène à la troisième: il incombe à l'opposition de prouver sa demande, pas à moi de la réfuter. Et en plus du problème de vraisemblance, j'ai présenté un argument factuel sans rapport avec lequel mon style de codage était fondé.
Konrad Rudolph

4
@ Konrad - python ne montre pas le contraire car l'indentation est significative et donc les accolades sont implicites. Les bons programmeurs brillants, le type qui est ici, ne feront probablement pas l’erreur souvent, voire pas du tout (depuis de nombreuses années, j’ai probablement déjà rencontré des problèmes avec seulement quelques occasions), mais il y en a beaucoup moins bons Les programmeurs qui font des bêtises sont l'une des raisons pour lesquelles des normes de codage sont nécessaires. (Et parce que les délais et le stress peuvent rendre le meilleur de nous moins bon.)
Murph

19

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.


11
absolument! Après tout, si le code était difficile à écrire, il devrait également être difficile à maintenir! ;-)
Steven A. Lowe

3
@ Steven Si vous oubliez les attelles, je pense qu'il y a d'autres problèmes ici.
TheLQ

more succint == moins verbose
UncleZeiv

5
@SnOrfus: quelque peu sarcastique, car les 2 caractères supplémentaires sont une surcharge triviale et évitent une erreur de maintenance très courante. Votre kilométrage peut varier ;-)
Steven A. Lowe

1
Pour moi, l'indentation indique clairement ce qui se passe. La première forme brûle de l’espace supplémentaire à l’écran et est donc un point négatif pour moi.
Loren Pechtel le

16

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


1
Mes pensées exactement. Si la déclaration simple a l'air bien sur une seule ligne après la ifclause, je n'utilise pas d'accolades. Pour toute autre ifdéclaration (ou toute déclaration utilisant plusieurs lignes), j'utilise toujours des accolades. En particulier, s'il y a une elseclause, chaque cas a toujours des accolades.
eswald

9
Je n'ai jamais vu quelqu'un confondre perl avec pseudocode auparavant. Caractères aléatoires oui, pseudocode - non.
Joe D

3
Je me demande si quelqu'un a créé un générateur de programme Perl en connectant simplement / dev / random à un interprète Perl ...
Christian Mann

J'aime l'approche de Ruby ici. Il offre le style perl sur une ligne <statement> if <condition>ou sur un bloc multiligne if <condition>/ <do something>/ end(ruby évite les accolades, l’accolade d’ouverture est donc implicite ifet l’accolade finale est remplacée par un littéral end). Il n'offre même pas la déclaration bizarre si, multiligne, mais vraiment, juste une ligne.
Ben Lee

One-Liner ne fonctionne pas avec la plupart des débogueurs (il n'est pas possible de déclencher une pause lorsque le contenu de la clause 'if' est sur le point d'être exécuté).
Peter Mortensen

11

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.


10

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.


3
Exactement! Ce n'est pas notre faute s'il ne connaît pas la syntaxe.
kirk.burleson

3
Mauvais exemple Une bonne voiture est une voiture avec des pédales mal placées - de l’essence au lieu d’un frein. C'est votre voiture, alors vous ne vous souciez de personne. C'est le problème qu'ils ne connaissent pas votre positionnement unique de pédales. Êtes-vous un bon ingénieur automobile dans ce cas?
Yegor256

Ce serait de ta faute si tu leur donnais ta voiture en sachant qu'ils pourraient être saouls. De même, nous devrions essayer de supposer le moins possible de futurs développeurs pour faciliter la maintenance.
Aram Kocharyan

8

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.


3
Je n'achète pas catégoriquement l'allégation de lisibilité. Python est l’un des langages les plus lisibles et n’a pas besoin de délimiteurs. Cette affirmation n’est tout simplement pas vraie. Je n'achète pas non plus l'allégation de maintenabilité, car elle n'a pas encore été prouvée et qu'elle a été réorganisée à plusieurs reprises. Mais dans ce cas, je suis réellement très intéressé par les preuves empiriques. C’est quelque chose qu’une étude pourrait très facilement découvrir et régler une fois pour toutes.
Konrad Rudolph

Comme Python utilise l'indentation au lieu de délimiteurs, ils sont implicites, ce qui n’est pas une comparaison valable.
Murph

@ Konrad - preuve empirique: Quand j'étais nouveau programmeur, j'ai personnellement ajouté du code à un bloc if non calé si, sans me rendre compte que le programmeur précédent ne s'était pas ennuyé avec des accolades. J'ai personnellement vu d'autres personnes le faire de mes propres yeux. D'accord, une seule fois, j'ai vu quelqu'un avoir besoin d'aide pour trouver le problème après avoir exécuté son code, mais cela était davantage dû à de mauvaises compétences de test.
Shimonyk

@shimonyk: Donc, en gros, vos observations corroborent mon affirmation selon laquelle ce problème est sans importance? En passant, les observations personnelles sont des anecdotes et ne sont pas considérées comme des preuves empiriques.
Konrad Rudolph

@ Konrad très bien, veuillez citer vos sources également. Je suppose que vous faites référence à une étude à double insu contrôlée par les pairs? Sinon, se contenter de faire fi de ses propres anecdotes pour tenter de prouver que les autres ont tort, tout en demandant à une autre personne de se référer à une "preuve" est au mieux hypocrite. Comme quelqu'un de plus bas sur ce sujet a écrit: "Il incombe à l'opposition de prouver ce qu'il prétend, pas à moi de la réfuter".
Shimonyk

7

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


4
J'avais l'habitude de faire cela, mais l'argument voulant que les programmeurs aient besoin de connaître le langage et que l'on doive les amener à réfléchir l'emporte.
kirk.burleson

2
Je considère cela comme une simple courtoisie envers mon futur moi.
Steven A. Lowe

5

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.


Si vous allez écrire des macros, vous devez les écrire pour vous assurer qu'elles peuvent être insérées dans n'importe quelle partie du code sans se rompre de toute façon.
Covar

4

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

3

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.


1
Je n'ai jamais vu personne commettre l'erreur dont vous parlez.
kirk.burleson

1
Je viens de faire hier sur le morceau de code de quelqu'un d'autre. :-) Je me demande simplement comment sera l’amont en amont, entre autres ajouts au code, en ajoutant des accolades à tous ses éléments car il semble vraiment être d’un autre côté que moi. :-) (calmez-vous, je plaisante, édité juste ce que je devais ...)
Vedran Krivokuća

2

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.


1

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!");

Suppose que quelqu'un n'est pas fan de brièveté.
JohnFx

2
La brièveté pour la lisibilité? Absolument pas. C'est du code, pas un concours de golf.
Josh K

3
Je pense que la lisibilité est une excellente raison de concision, personnellement. Dans tous les cas: les espaces blancs ne comptent pas dans mon livre de règles code-golf.
JohnFx

Le seul problème avec cela, c'est qu'il se prête à des abus
Conrad Frix

2
Alors n'en abusez pas. Je ne dis pas l'utiliser comme norme de codage. Il arrive souvent que vous ayez une condition brève, suivie d'une déclaration simple, et cela fonctionne bien. Par exemple, un if (assert) log.write ("assert failed");
JohnFx

1

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

Intéressant, je ne vois pas vraiment de code comme celui-ci, mais je l'aime bien.
Thomas Eding

0

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.


Vous pouvez tout aussi facilement utiliserreturn (obj != null) ? obj : "Error";
Josh K

@Josh, see edit
Note pour

Dans ce cas, je voudrais utiliser quelque chose comme Object returnObj = defaultObj; /* Three else-if's to change it to obj1/2/3 */ return returnObj;.
Josh K

@Josh, lisez stackoverflow.com/questions/36707/… . Premier commentaire sur la première réponse, "Même si avoir plusieurs points de sortie peut devenir incontrôlable, je pense vraiment que c'est mieux que de mettre toute sa fonction dans un bloc IF ."
Note to self - pensez à un nom

0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.