私はこのメソッド(変更されたコード)を持っています:
public static void PublishXmlForCustomTypes(MyOwnClass DefaultOutputInformation)
{
if (DefaultOutputInformation != null)
{
///lot of code
}
}
そして、私のコード全体がifステートメントの中にあり、それについて考えた後、私はこれに変更しました:
public static void PublishXmlForCustomTypes(MyOwnClass DefaultOutputInformation)
{
if (DefaultOutputInformation == null)
{
return;
}
///lot of code
}
私がそれをテストした限りでは、それは厳密に同等であるように思われますが、それは本当ですか?つまり、「return」ステートメントはメソッドから抜け出しますか?
これは厳密に同等であり、2番目のバージョンが方法です:)
はい、それは絶対に大丈夫です。
一部の人々は「メソッドごとに1つの出口点」に独断的に固執します-これは、たとえばCの関数の最後で常に適切な量のクリーンアップを行うことが比較的難しい場合に適切でしたが... C#では実際には必要ありません。
個人的には、メソッドで本当にやりたいすべての作業を完了したことがわかったらすぐに戻ることが適切だと思います。使用する try/finally
またはusing
ステートメントを使用して、「終了してもクリーンアップ」を実行します。
はいreturn
は、メソッドから抜け出します。 finally
ブロックがあり、try
ブロックからreturnを呼び出した場合、finally
ブロックが実行されます。
はい、returnステートメントはメソッドを終了します。
はい、戻るとコードが終了します。関数の最初のステップとして、渡されたパラメーターが想定どおりであることを確認し、(リターンまたは例外をスローして)終了することを確認して、不要な処理のみを行わないようにすることをお勧めします。関数の後半で中止する必要があります。
改訂されたコードを見ると、2番目のコードが進むべき方法です。機能的には同等ですが、確認したい関数に4つの異なる変数を渡した場合を考えてください。 {がどこにでもある厄介な4レベルのifステートメントを行う代わりに、2番目の方法では、不要なレベルの括弧を追加せずにコードの外観をクリーンアップできます。 C/C++で記述している場合、これをVERYIFY_NOT_NULL(x)などのマクロにして、コードをすてきできれいにすることもできます。
読み取り/保守可能なコードは、99%の時間でナノ秒のパフォーマンスに勝ります。
はい、あなたの仮定は正しいです。
背景については、 duality について学習してください。
はい、まったく同じです。キーワードリターンに関するMSDNドキュメントを読んで、その仕組みを完全に理解できます。 http://msdn.Microsoft.com/en-us/library/1h3swy84.aspx =
どちらの方法が良いかを決定することに関して:両方とも良いですが、2番目のバージョンではコード全体がifブロック内にないため、読みやすくなります。これにより、メソッドのコード全体を読み取る代わりに、条件が実際に何をするかを簡単に確認できます。
実際、return
はメソッドから抜け出すので、最初に使用した方法と同等です。どちらの方法が良いかはコードによって異なりますが、一般的には2番目のバージョンを使用します。