Apparemment, votre question n'est pas de savoir si les courts-circuits sont bons ou mauvais en général, mais pourquoi VB.NET fournit des opérateurs avec et sans. Dans cet esprit, la réponse à
quand l'évaluation des courts-circuits est-elle mauvaise?
est tout simplement: quand il viole la compatibilité descendante .
Ok, vous pouvez maintenant dire que VB.NET n'est pas très rétrocompatible avec les anciens VB6 ou VBA, mais au moins certaines parties du langage le sont. La décision de Microsoft de conserver les anciennes sémantiques ET et OU (sans court-circuit) a rendu une énorme catégorie d'erreurs moins susceptible de se produire lors du portage d'anciens programmes VB sur VB.NET.
D'un autre côté, les concepteurs du langage VB.NET ont probablement partagé votre opinion sur le fait que le court-circuit était une bonne chose. Si je me souviens bien, les premières versions préliminaires de VB.NET fournissaient aux opérateurs AND ou OR un court-circuit, mais les commentaires des développeurs devaient être si mauvais que MS retire cette décision avant l'apparition de VB.NET 1.0. Les concepteurs ont donc décidé de l'implémenter en termes de nouveaux mots clés ANDALSO
et en ORELSE
tant que compromis entre la compatibilité descendante et l'utilité.
À mon humble avis, c'était une bonne décision. J'ai dû porter plusieurs programmes plus anciens au cours de la dernière décennie, et le fait de ne pas avoir à effectuer une analyse d'impact lourde pour chaque expression logique, y compris AND et / ou OR (jeu de mots), a rendu cette tâche beaucoup plus facile et plus économique. D'un autre côté, chaque fois que je dois écrire une nouvelle expression logique dans VB.NET, mon choix par défaut pour les opérateurs sont les formes de court-circuit, c'est à cela que je suis habitué en C, C ++, C # etc, et cela permet moi d'écrire plusieurs idiomes sous une forme plus concise (même si ANDALSO a besoin de 4 caractères de plus pour taper).
Si vous n'êtes pas convaincu, je vous recommande de lire le grand article de Joel Spolsky sur les casques martiens , qui explique pourquoi les premières décisions de conception dans le développement de logiciels ne peuvent pas être facilement révoquées après que le composant ou le langage ou l'API en jeu a atteint une base d'utilisateurs d'une certaine taille .