Quand utiliser If-else si-else sur les instructions de commutateur et inversement

Question

Pourquoi voudriez-vous utiliser un bloc de commutateurs sur une série d'instructions if ?

Les instructions switch semblent faire la même chose mais prennent plus de temps à taper.

Answer 1

Comme avec la plupart des choses que vous devriez choisir lequel utiliser en fonction du contexte et de ce qui est conceptuellement la bonne façon de procéder. Un commutateur est en train de dire "choisir l'un de ces sur cette base les variables de la valeur", mais une instruction if est juste une série de booléenne contrôles.

Par exemple, si vous étiez en train de faire:

int value = // some value
if (value == 1) {
    doThis();
} else if (value == 2) {
    doThat();
} else {
    doTheOther();
}

Ce serait beaucoup mieux représenté comme un interrupteur, comme il fait alors immédiatement évident que le choix de l'action est en cours, basée sur la valeur de la "valeur" et non pas arbitraire de test.

Aussi, si vous trouvez vous-même écrit des commutateurs et des si-elses et à l'aide d'un langage OO vous devriez envisager de se débarrasser d'eux et de l'utilisation du polymorphisme pour obtenir le même résultat si possible.

Enfin, concernant le commutateur prend plus de temps à taper, je ne me souviens pas qui a dit cela, mais je n'ai lu une fois quelqu'un demander "est votre vitesse de frappe vraiment la chose qui affecte la façon dont rapidement vous le code?" (paraphrasé)

Answer 2

Si vous activez la valeur d'une seule variable, j'utiliserais un commutateur à chaque fois, c'est pour cela que la construction a été conçue.

Sinon, restez avec plusieurs déclarations if-else.

Answer 3

concernant la Lisibilité:

En général, je préfère si/d'autre construit sur instructions de commutation, en particulier dans les langues qui permet à l'automne-à travers des cas. Ce que j'ai trouvé, souvent, est que les projets de l'âge, et plusieurs développeurs s'en mêle, vous allez commencer à avoir des ennuis avec la construction d'une instruction switch.

S'ils (les états) devenir quelque chose de plus simple, beaucoup de programmeurs deviennent paresseux et au lieu de lire la déclaration complète de la comprendre, ils vont tout simplement pop dans un cas afin de couvrir ce cas, ils sont l'ajout dans la déclaration.

J'ai vu beaucoup de cas où le code se répète dans une instruction switch, car une personne de test a déjà été couverte, une simple chute-si cas aurait suffi, mais la paresse forcés à ajouter le code redondant à la fin au lieu d'essayer de comprendre le commutateur. J'ai aussi vu certains cauchemardesque instructions de commutation avec de nombreux cas qui ont été mal construits, et tout simplement en essayant de suivre la logique, avec de nombreuses automne-par le biais de cas dispersées, et de nombreux cas qui ne l'étaient pas, il devient difficile de ... le type qui conduit à la première/la redondance problème j'ai parlé.

Théoriquement, le même problème existe avec des if/else constructions, mais dans la pratique, cela ne semble tout simplement pas se produire aussi souvent. Peut-être (juste une supposition) les développeurs sont obligés de lire un peu plus attentivement, parce que vous avez besoin de comprendre l', souvent, de plus en plus complexe, les conditions sont testés dans le if/else construire? Si vous écrivez quelque chose de simple que vous connaissez d'autres sont susceptibles de ne jamais toucher, et vous pouvez construire eh bien, alors je suppose que c'est un tirage au sort. Dans ce cas, ce qui est plus lisible et qui se sent le mieux pour vous est sans doute la bonne réponse parce que vous êtes susceptible d'être le maintien de ce code.

concernant la Vitesse:

Les instructions Switch souvent plus rapide que si les autres constructions (mais pas toujours). Depuis les valeurs possibles d'une instruction switch sont prévues à l'avance, les compilateurs sont en mesure d'optimiser les performances, par la construction de sauter les tables. Chaque état n'a pas à être testé dans un if/else construire (bien, jusqu'à ce que vous trouver la bonne, de toute façon).

Cependant ce n'est pas toujours le cas. Si vous avez un interrupteur simple, disons, avec les valeurs possibles de 1 à 10, ce sera le cas. Plus les valeurs que vous ajoutez exige le saut tables à être plus grandes et l'interrupteur devient de moins en moins efficace (et pas qu'un if/else, mais moins efficace que le relativement simple instruction switch). Aussi, si les valeurs sont très variante ( c'est à dire au lieu de 1 à 10, vous avez 10 valeurs possibles de, disons, 1, 1000, 10000, 100000, et ainsi de suite pour 100000000000), le commutateur est moins efficace que dans le cas plus simple.

Espérons que cette aide.

Answer 4

Personnellement, je préfère voir des instructions switch par rapport à un nombre trop important d’esclaves, car elles peuvent être beaucoup plus faciles à lire. Les commutateurs sont également meilleurs en termes de lisibilité pour afficher un état.

Voir aussi le commentaire dans ce post concernant pacman ifs .

Answer 5

La tendance à éviter les trucs parce que la frappe est plus longue est une mauvaise chose, essayez de les éliminer. Cela dit, les choses trop verbeuses sont également difficiles à lire. Il est donc important de prendre une petite taille et simple, mais c'est la lisibilité et non la capacité d'écriture qui est importante. Les lignes simples concises peuvent souvent être plus difficiles à lire qu’un simple fichier bien agencé de 3 ou 4 lignes.

Utilisez la construction qui décrit le mieux la logique de l’opération.