条件が1つしかないifステートメントよりも切り替えを好む理由はありますか？

Question

チームのプロジェクトで次のコードを見つけました：

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

関数に戻り値の型がないことを気にしないでください（「ブール値として」を簡単に追加できます）。私が疑問に思っているのは、次の（私にとっては、はるかに読みやすい）コードよりも上記を好む理由はありますか？

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

質問を一般的な言葉で言うと： switch （または、この場合は Select Case ）ブロックを使用するのは理にかなっていますか？ブロック-単一の条件をテストするには？これは、単純な if よりも高速ですか？

Answer 1

パフォーマンスが心配な場合は...プロファイル。そうしないと、読みやすさの点で間違いを犯すことはありません...

Answer 2

実際には速度の点で重要だとは思わないが、コンパイラーはそれを最適化できるはずだ。

それは単に好みの問題だと思います。

Answer 3

経験則では、if / else条件の数が3より大きい場合にswitchステートメントを使用します。 if / else条件の数が増えるにつれて、読みやすさ/保守性が低下するように見える以外に、これが理にかなっている理由の背後にはデータがありません。

Answer 4

あなたが与えた特定のケースでの答えはノーだと思います-他の答えで提案されているように、コンパイラは実用的な違いを最適化することを望みます。

切り取り、貼り付け、削除のコーディングに少しお金をかけました-ネストされたcaseステートメントの一般化されたセットを取得し、必要なyes / noの結果を与える1ビットを抽出します。

これがインラインに似ているか、リターンフラグが設定されている関数呼び出しがあった場合は、おそらく、正当化を開始できるが、現状のままではない可能性があります。