Pour les besoins de ma discussion, un Bool peut avoir 2 états, True ou False. Tout le reste n'est pas conforme à la spécification de programmation Langugae. Si votre chaîne d’outils n’est pas conforme à ses spécifications, vous êtes blessé, peu importe ce que vous faites. Si un développeur crée un type de Bool comportant plus de 2 états, c'est la dernière chose qu'il ferait dans ma base de code.
Option A.
if (var == true) {
...
} else if (var == false) {
...
} else {
...
}
Option B
if (var == true) {
...
} else {
...
}
J'affirme que l'option B est plus robuste .....
Tout twit peut vous dire de gérer les erreurs inattendues. Ils sont généralement faciles à détecter une fois que vous y pensez. L'exemple que votre professeur a donné n'est pas quelque chose qui pourrait arriver, c'est donc un très mauvais exemple.
A est impossible à tester sans harnais de test compliqués. Si vous ne pouvez pas le créer, comment allez-vous le tester? Si vous n'avez pas testé le code, comment savez-vous que cela fonctionne? Si vous ne savez pas que cela fonctionne, vous n’écrivez pas un logiciel robuste. Je pense qu'ils appellent encore cela un Catch22 (excellent film, regardez-le un jour).
L'option B est simple à tester.
Problème suivant, posez cette question à votre professeur: "Que voulez-vous que je fasse à ce sujet si un booléen n’est ni vrai ni faux?" Cela devrait mener à une discussion très intéressante .....
Dans la plupart des cas, un dépotoir est approprié, au pire, il gêne l'utilisateur ou coûte très cher. Que faire si, par exemple, le module est le système de calcul de la rentrée en temps réel de la navette spatiale? Toute réponse, aussi inexacte soit-elle, ne peut être pire que d’annuler, ce qui tuerait les utilisateurs. Alors que faire, si vous savez que la réponse peut être fausse, optez pour le 50/50, ou abandonnez et tentez l'échec à 100%. Si j'étais un membre de l'équipage, je prendrais le 50/50.
L'option A me tue L'option B me donne une chance égale de survie.
Mais attendez - c'est une simulation de la rentrée dans la navette spatiale - alors quoi? Abort pour que tu saches. Cela vous semble une bonne idée? - NON - parce que vous devez tester avec le code que vous prévoyez d'expédier.
L'option A est préférable pour la simulation, mais ne peut pas être déployée. C'est inutile L'option B étant le code déployé, la simulation fonctionne de la même manière que les systèmes en direct.
Disons que c'était une préoccupation valable. La meilleure solution serait d'isoler le traitement des erreurs de la logique d'application.
if (var != true || var != false) {
errorReport("Hell just froze over, var must be true or false")
}
......
if (var == true){
....
} else {
....
}
Lecture ultérieure - machine à rayons X Therac-25, échec de la fusée Ariane 5 et autres (Link a beaucoup de liens cassés mais suffisamment d’informations pour que Google puisse vous aider)