Quelqu'un a-t-il / peut-il défier Oncle Bob de son amour de supprimer les «appareils inutiles»?

94

Je déteste faire référence à un contenu payant, mais cette vidéo montre exactement ce dont je parle. Précisément 12 minutes dans Robert Martin regarde ceci:

Du code

Et dit: "Une de mes choses préférées à faire est de se débarrasser des accolades inutiles" en le transformant en ceci:

Plus de code

Il y a longtemps, dans une formation lointaine, on m'avait appris à ne pas faire cela, car il est facile d'introduire un bogue en ajoutant une autre ligne indentée pensant qu'elle est contrôlée par le ifmoment où ce n'est pas le cas.

Pour être juste avec Oncle Bob, il refacture une longue méthode Java en minuscules petites fonctions qui, j'en conviens, sont beaucoup plus lisibles. Quand il a fini de le changer, (22.18) cela ressemble à ceci:

Encore plus de code

Je me demande si cela est censé valider la suppression des accolades. Je connais déjà la meilleure pratique . Oncle Bob peut-il être mis au défi sur ce point? Oncle Bob a-t-il défendu cette idée?

confits_orange
la source
6
Je vote pour clore cette question hors sujet, car toute réponse à cette question sera "non" ou "oui, et voici une citation".
Blrfl
35
Donnez-lui quelques années, il supprimera peut-être aussi le saut de ligne inutile et "si (voyez (quelque chose)) dites (quelque chose);" sera en fait être une ligne de code ;-)
Steve Jessop
8
@SteveJessop C'est bien d'apprendre que j'ai des années d'avance. : D Sans la nouvelle ligne, il n'y a aucun risque du fameux bug. Ajouter / supprimer des accolades au besoin est une charge supplémentaire, mais beaucoup plus est enregistré lors de la lecture.
Maaartinus
9
Oncle Bob fait quelques bons points pour le faire en code propre page 35. Si un ifbloc ne jamais une ligne, il n'a pas d' importance. Si vous devez ajouter plus de lignes, cela devrait être une autre fonction qui réduit le ifbloc à une ligne (l'appel de fonction). Si vous vous en tenez à cela, les accolades n’ont tout simplement aucune importance .
13
il devrait le faire return (page==null) ? "" : includePage(mode,page);s'il en veut un tant soit peu ... Je pensais que le style sans attelle était cool jusqu'à ce que je commence à développer des applications de manière professionnelle. Diff bruit, bugs de typo possibles, etc. Les accolades, étant là tout le temps, vous font économiser le temps et les frais généraux dont vous auriez besoin pour les introduire plus tard.
vaxquis

Réponses:

47

La lisibilité n'est pas une mince affaire.

Je suis d'un esprit mélangé quand il s'agit de croisillons qui enferment une seule méthode. Personnellement, je les supprime pour des choses comme des déclarations sur une seule ligne, mais le fait de laisser de tels crochets nous a en fait mordu très fort au dernier endroit où j'ai travaillé. Quelqu'un a ajouté une ligne de code à une ifinstruction sans ajouter également les accolades nécessaires et, comme il s'agissait de C, le système s'est écrasé sans prévenir.

Je ne mets jamais au défi quiconque est religieux de toujours utiliser des attelles après ce petit fiasco.

Je vois donc l’avantage de la lisibilité, mais je suis tout à fait conscient des problèmes qui peuvent survenir lorsque vous omettez ces accolades.

Je ne prendrais pas la peine d'essayer de trouver une étude ou l'opinion publiée de quelqu'un. Tout le monde en a un (c'est-à-dire une opinion), et comme il s'agit d'un problème stylistique, un avis est à peu près aussi bon qu'un autre. Réfléchissez vous-même au problème, évaluez le pour et le contre et décidez vous-même. Si le magasin pour lequel vous travaillez a une norme de codage qui couvre ce problème, suivez-le.

Robert Harvey
la source
7
J'ai été un peu mordu par cela trop récemment, quand l'indentation était éteinte et trompeuse.
Andy
12
Parce que c'était C sans GCC 6-Wmisleading-indentation .
wchargin
2
@CandiedOrange: C'est l'oncle Bob qui défie le dogme établi.
Robert Harvey
1
@RobertHarvey N’ai-je pas précisé cela? Oui, il défie le dogme. Il défie mon dogme. J'essaie juste d'être un bon élève et au moins, réfléchis-y. Mais oncle Bob est tellement charismatique que je me demande si je perds mon objectivité. Je demande donc de l'aide pour trouver un antidote avant de boire la koolaid.
candied_orange
1
@CandiedOrange: C'est absolument une question de contexte. Ceux qui acceptent aveuglément le dogme ne considèrent pas le contexte; ce sont eux qui utilisent encore la règle du «retour unique» dans les langues gérées, longtemps après que la règle a perdu son utilité et est devenue un obstacle.
Robert Harvey
133

Vous pouvez trouver plusieurs promotions publiées ou des rejets de styles sans attelle ici ou ici ou partout où des hangars à vélos sont peints.

En vous éloignant des abris à vélo, vous souvenez-vous de l'excellent bogue SSL OS X / iOS de 2014?

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
    goto fail;

Oui, "causé" par des blocs sans attache https://www.imperialviolet.org/2014/02/22/applebug.html

Les préférences peuvent dépendre du style d'accolade. Si je devais écrire

if (suiteSetup)
{
    includePage(mode, suiteSetup);
}

Je pourrais être enclin à économiser de l'espace aussi. Mais

if (suiteSetup) {
    includePage(mode, suiteSetup);
}

utilise uniquement une ligne "extra".


Je sais que vous n'avez pas demandé, mais si je travaille seul, je suis un hérétique. Si je retire les bretelles, je préfère

if (suiteSetup != null) includePage(mode, suiteSetup);

Il n'a pas le même problème visuel que le bogue de style SSL iOS, mais enregistre encore plus de lignes "inutiles" qu'Oncle Bob;) Lit bien si vous y êtes habitué et a une utilisation courante dans Ruby ( includePage(mode, suiteSetup) unless suiteSetup.nil?). Oh bien, sachez qu'il y a beaucoup d'opinions.

Paul Draper
la source
13
De plus, si vous utilisez } else[if(...)] {, cela n’ajoute pas de lignes supplémentaires, ce qui fait qu’il n’a qu’une seule ligne supplémentaire.
Random832
12
Je suis heureux que vous ayez soulevé le bogue SSL iOS. Depuis lors, je me suis retrouvé de plus en plus à utiliser des appareils dentaires.
Zach Lipton
4
En ce qui concerne le bug "goto fail", il est intéressant de noter que d'autres aspects du style de codage d'oncle Bob l'auraient également empêché, notamment sa forte préférence pour les méthodes extrêmement courtes. Il n'aurait jamais toléré une méthode à 79 lignes au départ, et si la méthode avait été divisée en méthodes plus petites, (a) le conflit de fusion à l'origine de la duplication ne serait probablement jamais arrivé et (b) le contrôle de flux plus simple dans la méthode aurait probablement signifié que des avertissements du compilateur pour du code inaccessible auraient été générés, ce qui aurait dû empêcher le problème.
Jules
16
"goto fail" n'a pas été provoqué par des blocs d'une seule ligne, mais par une programmation peu scrupuleuse, une révision du code encore plus compliquée et par une seule et même défilement manuel du code.
gnasher729
35
Meh, le manque d'accolades n'a pas causé ce bug. Les programmeurs épouvantables (et l'absence de révision de code significative, de tests) l'ont fait. Résolvez le problème en renvoyant les responsables, et non en nous liant les mains!
Courses de légèreté en orbite
62

Oncle Bob dispose de nombreuses couches de défense contre une telle erreur qui n’était pas aussi courante quand "toujours utiliser des accolades" était la sagesse qui prévalait:

  1. Une forte préférence personnelle pour les conditionnels sur une ligne, de sorte que ceux multi-lignes se distinguent et font l'objet d'un examen minutieux.
  2. Un éditeur qui se démarque automatiquement lorsque vous insérez une deuxième ligne.
  3. Une suite complète de tests unitaires qu'il exécute constamment.
  4. Une suite complète de tests d'intégration.
  5. Une évaluation par les pairs effectuée avant la fusion de son code.
  6. Une réexécution de tous les tests par un serveur d'intégration continue.
  7. Tests effectués par un service qualité produit.

Je pense que si quelqu'un publiait un défi contre Oncle Bob, il aurait une assez bonne réfutation avec les points ci-dessus. C'est l'une des erreurs les plus faciles à détecter tôt.

Karl Bielefeldt
la source
16
Je n'ai jamais craint les accidents comme je crains les choses qui échouent en silence. Au moins, vous savez quand un accident se produit. L'arrière de mon cerveau me chatouille lorsque je vois ce genre de choses. Ça pique de la même façon que quand je vois while(true);{break;}. S'il existe vraiment un contexte valable pour cela, il me faudra un certain temps pour le surmonter.
candied_orange
9
Avons-nous un moyen automatisé de vérifier que la includePage()macro n’est pas mal écrite avec plus d’une déclaration?
Martin York
51
@ LokiAstari Oui, cela s'appelle "Java n'a pas de macros".
svick
11
Toutes les réponses ci-dessus sont davantage des "moyens d'éviter que les inconvénients liés à la politique" d'inutiles accolades "me blesse" plutôt qu'en réalité "des raisons d'utiliser la" politique d'inutiles inutiles ". Les faits dont vous avez besoin (particulièrement le numéro 1) doivent être considérés davantage comme un désavantage que comme un avantage.
SJuan76
16
@Jules Oh oui! TOUS les produits que j'ai reçus ou mis en marché au travail ont une couverture de test de 100% (au minimum), sont évalués par des pairs (plusieurs fois) et toutes les entreprises du secteur ont un département d'assurance logiciel. Oui. Je suppose que vous avez trouvé la même chose dans votre carrière professionnelle, car chaque entreprise a des équipes de programmeurs au lieu de programmeurs uniques et leur donne plus de temps que nécessaire pour effectuer tous les tests qu’ils souhaitent effectuer. Oui, cela décrit parfaitement tous les lieux de travail. Pourquoi devrait-on s’inquiéter de l’ajout de bogues supplémentaires quand nous sommes sûrs que notre logiciel est expédié TOUJOURS à 100% sans bogues?
SJuan76
31

Pour la plupart, il s'agit d'une préférence personnelle, mais il y a certaines choses à considérer.

Bugs possibles

Bien que l' on peut soutenir que les bugs causés par l' oubli d'accolades add-in sont rares, de ce que j'ai vu que ils ne se produisent de temps en temps (ne pas oublier le fameux goto IOS échec bug). Donc, je pense que cela devrait être un facteur lors de l'examen de votre style de code (certains outils vous avertissent de l' indentation trompeuse , donc cela dépend aussi de votre chaîne d'outils) .

Code valide (qui se lit comme si cela pouvait être un bogue)

Même en supposant que votre projet ne souffre pas de tels bogues, lors de la lecture du code, vous pouvez voir des blocs de code qui pourraient ressembler à des bogues - mais ne le sont pas, prenant en compte certains de vos cycles mentaux.

Nous commençons par:

if (foo)
    bar();

Un développeur ajoute un commentaire utile.

if (foo)
    // At this point we know foo is valid.
    bar();

Plus tard, un développeur l'étend.

if (foo)
    // At this point we know foo is valid.
    // This never fails but is too slow even for debug, so keep disabled.
    // assert(is_valid(foo));
    bar();

Ou ajoute un bloc imbriqué:

if (foo)
    while (i--) {
        bar(i);
        baz(i);
    }

Ou utilise une macro:

if (foo)
    SOME_MACRO();

"... Étant donné que les macros peuvent définir plusieurs lignes de code, la macro utilise- do {...} while (0)t-elle plusieurs lignes? Ce devrait être parce que c'est dans notre guide de style, mais je ferais mieux de vérifier au cas où!!"


Les exemples ci-dessus sont tous du code valide. Cependant, plus le contenu du bloc de code est important, plus vous devez lire pour vous assurer qu'il n'y a pas d'erreur.

Peut-être que votre style de code définit que les blocs multilignes nécessitent une accolade (peu importe le type, même s'ils ne sont pas du code) , mais j'ai déjà vu ce genre de commentaires être ajoutés au code de production. Lorsque vous le lisez, il y a un petit doute sur le fait que celui qui a modifié ces lignes en dernier ait oublié d'ajouter une accolade. Parfois, je ressens le besoin de vérifier si tout se passe bien (surtout lorsque vous recherchez un bogue dans cette partie du code) .

Diff bruit

Une raison pratique d'utiliser des accolades pour des lignes simples est la réduction du bruit diff .

C'est-à-dire changer:

if (foo)
    bar();

À:

if (foo) {
    bar();
    baz();
}

... provoque l'affichage de la ligne conditionnelle dans un diff comme étant modifiée, ce qui ajoute une surcharge légère mais inutile.

  • les lignes apparaissent comme étant modifiées dans les révisions de code, si vos différents outils sont basés sur des mots, vous pouvez facilement voir que seul l'accolade a été modifiée, mais cela prend plus de temps à vérifier que si la ligne n'a pas changé du tout.
    Cela dit, tous les outils ne prennent pas en charge la différenciation basée sur les mots: diff (svn, git, hg, etc.) montrera que si la ligne entière était modifiée, même avec des outils sophistiqués, vous devrez parfois parcourir rapidement une ligne simple. basé sur diff pour voir ce qui a changé.
  • Les outils d'annotation (tels que git blame) indiquent que la ligne a été modifiée, ce qui rend le suivi de l'origine d'une ligne plus complexe pour trouver le changement réel .

Celles-ci sont toutes deux petites et dépendent du temps que vous consacrez à la révision du code ou au suivi du code pour valider les lignes de code modifiées.

Un inconvénient plus tangible d'avoir des lignes supplémentaires change dans un diff, leur plus grande probabilité que des modifications dans le code provoquent des conflits qui se fusionnent et qui doivent être résolus manuellement .


Il y a une exception à cela, pour les bases de code qui ont {sur leur propre ligne - ce n'est pas un problème.

L' argument de bruit diff ne tient pas si vous écrivez dans ce style:

if (foo)
{
    bar();
    baz();
}

Cependant, ce n'est pas une convention si commune, donc il faut principalement ajouter la réponse pour la complétude (ne suggérant pas aux projets d'utiliser ce style) .

idéesman42
la source
8
J'aime la réduction du bruit diff commenté qui est un plus définir.
Martin York
2
Si seulement tous les fous de JSON avaient une quelconque considération pour le bruit de diff! Je te regarde, règle de non-dernière virgule.
Roman Starkov
1
Euh, je n'avais pas envisagé l'avantage de diff-noise du {style -on-its-own-line. Je déteste vraiment ce style et n'aime pas travailler sur des projets où ce style est requis. Peut-être avec cela à l'esprit, je trouverai un peu moins frustrant d'avoir à coder de cette façon. La densité de code est importante. Si vous pouvez voir toutes les fonctions à la fois sur votre moniteur, vous pouvez plus facilement tout comprendre. J'aime laisser des lignes vides entre des blocs de code distincts à l'intérieur d'une fonction pour des raisons de lisibilité (pour regrouper les déclarations associées), et être obligé de perdre de l'espace ailleurs, affaiblit les coupures prévues.
Peter Cordes
1
@ peter-cordes, qui n’est pas non plus un adepte du {style en ligne, ne l’a inclus que pour l’intégralité des réponses. En ce qui concerne les macros de confiance à utiliser do{}while(0), je trouve que le problème est que vous pouvez y faire confiance presque tout le temps. Le problème, c’est que des accidents surviennent, que des erreurs peuvent se glisser lors de la révision du code ... et que des bugs peuvent être introduits, qui ne seraient pas autrement.
ideasman42
2
Si nous répertorions des bogues potentiels, la possibilité de commenter des lignes individuelles est un autre avantage. Je cherchais un bug qui avait été provoqué par une personne commentant aveuglément le corps d'une déclaration if d'une ligne. L'instruction suivante a ensuite été exécutée sous condition, plutôt qu'exécutée sans condition.
Eldritch Cheese
15

Il y a des années, j'ai été amené à déboguer du code C. Le bogue était difficile à trouver, mais il a finalement abouti à une déclaration comme celle-ci:

if (debug)
   foo (4);

Et il s’est avéré que la personne qui l’avait écrite s’était définie foocomme une macro. Une macro avec deux lignes de code. Et bien sûr, seule la première de ces deux lignes était soumise à la if. (Donc, la deuxième ligne a été exécutée sans condition.)

Cela peut être absolument unique à C et à son pré-processeur - qui effectue les substitutions avant la compilation - mais je ne l’ai jamais oublié. Ce genre de chose vous marque, et pourquoi ne pas jouer prudemment - surtout si vous utilisez une variété de langages et d'outils et que vous ne pouvez pas être sûr que de telles manigances ne sont pas possibles ailleurs?

Maintenant, j'indente et utilise les accolades différemment des autres, apparemment. Pour une seule ligne if, je ferais:

if (debug) { foo (4); }

il ne faut donc aucune ligne supplémentaire pour inclure les accolades.

Wayne
la source
6
Dans ce cas, celui qui a écrit cette macro est celui qui est en faute.
gnasher729
6
Écrire correctement des macros du préprocesseur peut ne pas être intuitif, mais cela peut être fait. Et cela devrait être fait, comme le souligne gnasher729. Et votre exemple est la raison pour laquelle toute macro qui contient plusieurs instructions doit inclure son corps dans une do { ... } while(0)boucle. Cela garantira non seulement qu'il sera toujours traité correctement en englobant des if()instructions, mais également que le point-virgule à la fin de l'instruction sera avalé correctement. Quiconque ne connaît pas de telles règles simples ne doit tout simplement pas écrire de macros de préprocesseur. Défendre sur le site de l'appelant n'est pas le bon endroit pour se défendre.
cmaster
18
@cmaster: C'est vrai, mais la façon dont les macros (ou autres fonctionnalités du langage) sont écrites par d'autres est hors de mon contrôle. Comment j'utilise des accolades est sous mon contrôle. Je ne suis certainement pas en train de dire que c'est une raison impérieuse d'inclure des accolades, mais c'est quelque chose que je peux faire pour me défendre contre les erreurs des autres, alors je le fais.
Wayne
@ gnasher729, qui se soucie de savoir si c'est la faute de quelqu'un d'autre? Si vous effectuez des revues de code et que vous suivez des normes de code raisonnables, cela pourrait aussi bien être la faute de votre équipe. Et si cela parvient aux utilisateurs, ils vont s'en prendre à l'entreprise qui publie un logiciel buggy.
ideasman42
1
Celui qui a créé des macros est celui qui en est responsable.
Neme
14

"Oncle Bob" est autorisé à avoir son opinion, vous êtes autorisé à avoir votre opinion. Pas besoin de le défier.

Si vous voulez faire appel à l'autorité, prenez Chris Lattner. Dans Swift, si les instructions ont perdu leurs parenthèses, mais toujours avec des accolades. Aucune discussion, cela fait partie du langage. Donc, si "Uncle Bob" commence à supprimer les accolades, le code cesse de compiler.

Passer par le code de quelqu'un d'autre et "se débarrasser des accolades inutiles" est une mauvaise habitude. Ne provoque un travail supplémentaire que lorsque le code doit être révisé et que des conflits sont créés inutilement. Peut-être que "Uncle Bob" est un si bon programmeur qu'il n'a pas besoin de révision de code? J'ai perdu une semaine de ma vie parce qu'un des meilleurs programmeurs a changé "if (p! = NULL)" en "if (! P)" sans vérification du code, caché au pire endroit possible.

C'est surtout un débat de style inoffensif. Les accolades ont l’avantage de pouvoir insérer une autre ligne de code sans ajouter d’accolades. Comme une déclaration de journalisation ou un commentaire (s'il est suivi d'un commentaire suivi d'une déclaration, c'est horrible). instruction sur la même ligne que si a l'inconvénient pratique que vous avez des problèmes avec de nombreux débogueurs. Mais fais ce que tu préfères.

gnasher729
la source
1
Je suppose que c’est une question de "défi" parce que UB (sic!) Présente ses opinions comme des faits - du moins, cela m’a l’impression de le faire quand je l’écoute.
vaxquis
3
Dire "Faites ce que vous préférez", c'est en fait être d'accord avec Oncle Bob à ce sujet, car c'est ce qu'il soutient "cela n'a pas d'importance". Dans de nombreuses langues, ceci n'est pas un problème. J'avais déjà pensé que dans tous les cas où il y avait un problème, vous devriez TOUJOURS utiliser des accolades et je n'avais vu personne contester cela. Maintenant, voici Oncle Bob qui le conteste et je me demande s’il ne s’en tire pas parce qu’il utilise des méthodes aussi minutieusement remaniées, ou parce qu’il en est rempli. Je ne l'avais pas considéré comme inoffensif à cause du type de bugs mentionné par @PaulDraper dans sa réponse.
candied_orange
Re toujours : le bruit syntaxique est source de distraction et la ligne supplémentaire « blanc » pour l'accolade fermante ajoute un séparateur visuel dans le paragraphe où les lignes ne doivent pas être divisés à part, ce qui entrave encore la lisibilité. Ceci est particulièrement important dans les petits blocs concis que vous mentionnez.
JDługosz
9

Mes raisons pour ne pas enlever les accolades sont les suivantes:

  1. réduire la fatigue de décision. Si vous utilisez toujours des accolades, vous n'avez jamais à décider si vous allez en avoir besoin ou non.

  2. réduire la traînée de développement: même si vous essayez d' extraire éventuellement toutes les lignes de la logique en méthodes, vous devez convertir un sans bracelet si en une doublée si l'ajout de logique est un peu désagréable en matière de développement. Il faut donc supprimer les accolades et les rajouter lorsque vous avez besoin de plus de code. Minuscule, mais ennuyeux.

Michael Johnston
la source
0

Un jeune collègue a déclaré que les accolades que nous considérons comme redondantes et superflues lui sont en fait utiles. Je ne me souviens pas exactement pourquoi, mais si cela lui permet d'écrire un meilleur code plus rapidement, c'est la seule raison de le conserver.

FWIW, nous avons convenu d'un compromis qui les mettre sur une ligne ne fait pas de telles conditions court un lecture / distrayant pour moi. Par exemple

if (!param) { throw invalid_argument (blahblah); }
if (n < 2) { return 0; }
// real code for function starts here...

Je souligne également que ces conditions préalables d'introduction sont souvent des déclarations de flux de contrôle pour le corps (par exemple, un return), de sorte que la crainte d'ajouter une deuxième déclaration censée être dans les mêmes conditions et d'oubli pour écrire des accolades est sans objet. Une seconde déclaration sous la condition serait de toute façon un code mort et n'aurait aucun sens.

Je soupçonne que le problème de la maîtrise de la lecture est dû au fait que l'analyseur cérébral de la personne est câblé pour que les accolades fassent partie intégrante de l'énoncé conditionnel. Ce n'est pas une représentation précise de la grammaire du C ++, mais pourrait être un effet secondaire de l'apprentissage de certaines autres langues en premier, où c'est le cas.

JDługosz
la source
1
Oncle Bob pense probablement qu'il écrit un meilleur code plus rapidement sans eux.
Djechlin
2
Tout comme moi et d'autres personnes parlent couramment C ++.
JDługosz
1
"Si cela lui permet d'écrire un meilleur code plus rapidement, c'est la seule raison de les garder" ++ J'ai un Jr. qui a dit la même chose, alors nous les conservons.
RubberDuck
... et c'est donc la seule raison de le faire comme oncle Bob le souhaite.
djechlin
-1

Après avoir visionné cette vidéo tout à l’heure, j’ai remarqué que l’élimination des accolades permettait de voir plus facilement où le code devait encore être refondu. Si vous avez besoin d'accolades, votre code peut probablement être un peu plus propre.

Cela dit, lorsque vous faites partie d’une équipe, l’élimination des accolades entraînera probablement un comportement inattendu un jour. Je leur dis de les garder et vous éviterez beaucoup de maux de tête en cas de problème.

Gijs Overvliet
la source
cela ne semble pas offrir quoi que ce soit de substantiel sur les points soulevés et expliqués dans les 10 réponses précédentes
gnat
-3

On m'a appris à ne pas le faire parce que cela facilite l'introduction d'un bogue en ajoutant une autre ligne indentée pensant qu'il est contrôlé par le if si ce n'est pas le cas.

Si votre code est bien testé , ce type de "bogue" exploserait au visage.

Nettoyer le code en évitant les crochets inutiles et laids est une pratique que je suis.

Mik378
la source
9
Bien entendu, l'inverse est également vrai: si votre code est exempt de bogues, vous n'avez pas besoin de tests unitaires. La réalité est que nous vivons dans un monde imparfait où il y a parfois des erreurs de code et parfois des erreurs dans les tests. (D'après mon expérience, ces dernières sont en réalité plus courantes.) Ainsi, bien que les tests réduisent certainement le risque d'insectes, ce n'est pas une excuse pour trouver d'autres moyens d'augmenter le risque.
Ruakh
3
Pour ajouter au commentaire de ruakh: il n'est pas possible de tester à 100% un code.
BЈовић
S'il vous plaît venez voir mon code;) Tout en pratiquant TDD, il est toujours possible de montrer ce genre de bogue très rapidement.
Mik378
@ Mik378 ce n'est certainement pas vrai. Le fait est que si vous utilisiez des accolades, vous n'auriez même pas à vous en soucier.
GoatInTheMachine