今私は、テキストボックスとコンボボックスの束を検証するためのサブを持っています。VB。 NET：ExitサブまたはネストされたIFステートメントといくつかのIFステートメントExit Subなし？
以前は、多くのIF文を使用して、さまざまなメッセージボックスを検証してポップアップし、すべてのIF文でExit Subを使用しました。
しかし、Exitsが多すぎると効率が低下すると聞きましたが、使用を推奨しませんでした。その代わりに、ネストされたIFはプロセスが自然に終了するようになるため、より優れています。
次に、ネストされたIFを使用すると、メッセージボックスがすべて条件から分離されているため、読みにくいことがわかりました。
私はソフトウェア開発の経験はありません。だから私の質問です：実際のプロジェクトでは、どのスタイルを選択しますか？
もっと読みやすいものとチームに同意するものを使用してください。
Exitsはパフォーマンスが低下していますが、それが本当かどうかはわかりませんが、たとえそうであったとしても、マイクロマイクロ最適化はそれほどごくわずかです。これは、あなた自身が簡単にテストできるものです。両方のタイプのコードをループ（何百万/何十億回）で実行し、それぞれがStopWatchクラスを使ってどれくらいの時間を費やしたかを測定します。
私は個人的に、この特定のケースでは複数のリターンを読みやすく、それは私の通常のスタイルです。
+1 IMHO、ほとんどの場合、読みやすさはパフォーマンスより重要です（パフォーマンスヒットが特に発音でない限り、この場合はそうではありません）。 – CJM
個人的には、処理のためにネストされたifsを使用し、事前条件検証にExit Sub/Functionを使用します。私はいくつかの開発者がExit Sub/Functionをウィンドウの外に投げて、returnキーワードだけを投げているのを見ました。
あなたの会社の目的が複雑であるかどうかによって異なります。多くの場合、Exit Sub/Functionステートメントを使用する理由は、サブシステム内および関数内の処理が始まる前に事前条件を検証することによって循環的複雑さを軽減するためです。ここでのアイデアは、事前条件の違反に基づいて終了することです。これはおそらくネストされたifの条件であり、循環的複雑さを劇的に減らし、コードの保守性を向上させます。
他のすべてのものと同様に、ここでは可読性に基づいてトレードオフがあります。 Exit SubsまたはExit関数が多すぎる場合、デバッグを介してそのメソッドを呼び出すと、メソッドが途中で終了した理由を混乱させる可能性があり、デバッグ時間が長くなります。
パフォーマンスの問題に関する議論があります。しかし、私はそれをテストしたことはありません。私は、ネストされたifを使用するのではなく、Exitを使用することに関連するパフォーマンス上の問題がないと言うことができます。
これはナンセンスです。聞いたことのすべてを信じてはいけません。ここでさえ、測定しないでください。それは、UIコードです。あなたは人間を幸せに保つだけです。あなたはそれを行うために1億CPUのサイクルを持っています。 –