4

私はちょうどこのように見えるいくつかのコードをデバッグしていました：

string someValue = _snuh.FindItem(id).Value;

FindItem()（は）の戻り値を調べたかったFooので、コードを2行に分割しました。

Foo foo = _snuh.FindItem(id);
string someValue = foo.Value;

これにより、デバッガーでfooを確認できました。コードがすべて1行にあると、私にはできなかったことがあります。

デバッグが完了したので、コードを元の状態に戻すか、2行のままにする必要がありますか？

4

6 に答える 6

5

2本の線は1本のライナーよりも優れています。

  • あなたはそれらをデバッグすることができます
  • nullポインタがある場合は、エラーログに行番号が表示されます（そして何が悪いのかを直接確認できます）
  • 読みやすい
  • ワンライナーが何をしているのかを説明するために追加のコメントは必要ありません
  • パフォーマンスに違いはありません（コンパイラーは同じILに最適化されます）
  • デバッグ後にコードを書き直すと、新しいタイプミスが発生する可能性があります
于 2013-03-26T13:52:03.033 に答える
4

あなたはそれを書くよりもあなたのコードを読む。

最も読みやすい形のままにしておきます。JITはとにかくあなたのコードを最適化します。

于 2013-03-26T13:52:10.797 に答える
3

私たちの職場では、コードスタイルのガイドラインでは、メソッド呼び出しの結果を変数に格納する必要があります。この背後にある考え方は、null参照例外がスローされた場合、行番号はどの変数がnullであるかを正確に示すということです。これは、メソッドの結果を直接操作した場合には不可能です。

実際には、このルールはある程度無視されます。特に、Linqメソッドがnullを返さないため、Linqクエリを実行する場合（ガイドラインはLinqが広く使用される前のものです）。

于 2013-03-26T13:53:07.567 に答える
3

Visual Studioでは、「イミディエイトウィンドウ」または「ウォッチの追加」を使用して、ステートメントの一部をデバッグし、追加の変数を使用せずにそれらの値を確認できます。

于 2013-03-26T13:53:18.623 に答える
3

このようなワンライナーを持っているのではなく

string someValue = _snuh.FindItem(id).Value;

私はむしろあなたが持っているようにリファクタリングしたい

string someValue = _snuh.FindItemValue(id);

FindItem()および後続のValue間接参照を関数にカプセル化します。

なんで ？最初のソリューションは、によって返されるオブジェクトの実装を公開しますFindItem（つまり、Valueフィールドがあります）。デメテルの法則は、2番目の変形を示唆しています。さらに、多くの場所でこれを行う必要がある場合は、繰り返しを回避します。nullチェックを実行する必要がある場合は、これを1回だけ実行する必要があります。

于 2013-03-26T13:54:30.723 に答える
2

個人的には、Null参照例外が発生しやすいため、「Value」プロパティにアクセスする前に、返されるオブジェクトを「NULL」チェックするとともに、2番目のアプローチを使用します。これは次のようになります。

string someValue = string.Empty;
Foo foo = _snuh.FindItem(id);
if (foo != null)
{
    someValue = foo.Value;
}

お役に立てれば！！

于 2013-03-26T13:53:28.963 に答える