どちらの方法がより良い習慣です:using
ステートメント内のメソッドから値を返すか、前に変数を宣言し、その中に設定して後で返しますか?
public int Foo()
{
using(..)
{
return bar;
}
}
また
public int Foo()
{
var b = null;
using(..)
{
b = bar;
}
return b;
}
どちらの方法がより良い習慣です:using
ステートメント内のメソッドから値を返すか、前に変数を宣言し、その中に設定して後で返しますか?
public int Foo()
{
using(..)
{
return bar;
}
}
また
public int Foo()
{
var b = null;
using(..)
{
b = bar;
}
return b;
}
私は最初の例を好みます。変数が少なく、コード行が少なく、フォローしやすく、保守しやすい...
public int Foo()
{
using(..)
{
return bar;
}
}
「lessismore」の原則(実際にはKISSの単なる変形)に従って、前者。維持するコードの行数が少なくなり、セマンティクスが変更されたり、読みやすさが失われたりすることはありません(おそらく、このスタイルの方が読みやすくなります)。
ステートメントの使用から-MSDN
usingステートメントは、オブジェクトのメソッドの呼び出し中に例外が発生した場合でも、Disposeが呼び出されるようにします。オブジェクトをtryブロック内 に配置し、finallyブロックでDisposeを呼び出すことで、同じ結果を得ることができます。実際、これはusingステートメントがコンパイラーによって変換される方法です。
try-finallyから(C#リファレンス)
最後に、前のtryブロックがどのように終了したかに関係なく、コードのステートメントブロックが実行されることを保証するために使用され ます。
あなたの質問に答えるために、はい、usingステートメントから戻っても大丈夫です。
2つ目は明らかに優れており、テストプログラムを作成することで正常に動作することを確認できます。
using
ステートメント自体に値を設定することはできません。これは制限事項です。Open
openを返すというメソッドがFileStream
あり、ファイルの長さを取得したいとします。
Console.WriteLine(Open().Length);
そこにあるバグは、あなたがを処分していないということですFileStream
。したがって、次のように記述する必要があります(例と同様)。
long length;
using (FileStream file = Open())
length = file.Length;
Console.WriteLine(length);
しかし、単純な拡張メソッドを使用すると、代わりに次のように記述できます。
Console.WriteLine(Open().Use(file => file.Length));
素晴らしく、きちんとしていて、FileStream
適切に処分されます。
そのステートメントがブロックにusing
変換され、パーツが実行されることが保証されているので、そうしない理由はありません(リターンまたは未処理の例外を介しても)。try...finally
finally
それは本当に個人的な好みに帰着します。この特定の柵の両側に議論があります。私自身、私はオプション1を好みます:できるだけ早く戻る。私はそれがコードの意図をよりよく表現していると信じています。あなたがしなければならないより長く立ち往生する理由はありません。すべての作業が完了したら、戻ってください。
場合によっては、複数の可能な戻りポイントと、単一のreturnステートメントにつながる可能性のある「メソッドの終了」作業(ロギング、クリーンアップ)があります。それについてひどいことは何もありませんが、多くの場合、これらの状況をfinally
ブロックで、またはアスペクト指向プログラミングのアスペクトで処理できます。
2番目の方が気分がいい
public int Foo()
{
using(..)
{
return bar;
}
}
この方法を使用しているときに頭に浮かぶことの1つは、使用の合間に戻ってくるので、オブジェクト(usingでラップしたもの)が破棄されることです。usingステートメントはtry /の混合物であるため、答えはyesです。 finallyブロック、tryブロックから戻るのも問題ありません。return式が評価され、finallyブロックが実行され、メソッドが返されます。