Existe-t-il une raison de préférer un passage à une instruction if avec une seule condition?

Question

J'ai trouvé le code suivant dans le projet de mon équipe:

Public Shared Function isRemoteDisconnectMessage(ByRef m As Message)
    isRemoteDisconnectMessage = False
    Select Case (m.Msg)
        Case WM_WTSSESSION_CHANGE
            Select Case (m.WParam.ToInt32)
                Case WTS_REMOTE_DISCONNECT
                    isRemoteDisconnectMessage = True
            End Select
    End Select
End Function

Peu importe que la fonction n'ait pas de type de retour (je peux facilement ajouter 'As Boolean'); Ce que je me demande, est-ce qu'il pourrait y avoir une raison de préférer ce qui précède au code suivant (pour moi, beaucoup plus lisible)?

Public Shared Function isRemoteDisconnectMessage(ByRef m As Message) As Boolean
    Return m.Msg = WM_WTSSESSION_CHANGE AndAlso _
           m.WParam.ToInt32() = WTS_REMOTE_DISCONNECT
End Function

Pour poser la question en termes généraux: est-il judicieux d’utiliser un commutateur (ou, dans ce cas, Sélectionner le cas ) - et / ou imbriqué blocs - pour tester une seule condition? Est-ce éventuellement plus rapide qu'un simple si ?

Answer 1

Si vous êtes inquiet pour la performance ... profil. Sinon, vous ne pouvez pas vous tromper en vous trompant de lisibilité ...

Answer 2

Je ne crois pas que cela importe réellement en termes de vitesse, le compilateur devrait pouvoir l’optimiser.

Je pense que ce serait simplement une question de préférence.

Answer 3

Ma règle empirique consiste à utiliser une instruction switch lorsque le nombre de conditions if / else est supérieur à trois. Je n'ai aucune donnée derrière la raison pour laquelle cela a du sens autre que la lisibilité / la maintenabilité semble diminuer à mesure que le nombre de conditions if / else augmente.

Answer 4

Je pense que la réponse dans le cas spécifique que vous avez donné est non. Cela n'a aucun sens, comme suggéré dans d'autres réponses, on espère que les compilateurs optimiseront les différences pratiques.

Je mettrais de l’argent sur le fait qu’il s’agisse d’un peu de découpage, de collage et de suppression de code - en prenant un ensemble généralisé d’instructions majuscules et en extrayant ce bit qui vous donne le résultat oui / non dont vous avez besoin.

S'il s'agissait de quelque chose de similaire en ligne et / ou s'il y avait un appel de fonction pour lequel l'indicateur de retour est défini, on pourrait éventuellement se trouver à un point où on pourrait commencer à le justifier mais pas tel qu'il est.