NullReferenceException
または不正な動作と出力の原因を調査することが容易になります。
繰り返しますが、深く理論化することはしませんが、どのように、どのようなシナリオでバリュートラッキングが機能するかを簡単に示します。
簡単な例
簡単な例を考えてみましょう。
VisitData
メソッドでは、
VisitData
が発生します
VisitData
がどこから来たのかを調べてみましょう。
VisitData
メソッドで
dc
パラメーターを使用するキャレットを配置し、分析を実行します（ R＃->
VisitData
> Value Origin ）：
public class Main
{
void Start()
{
Console .WriteLine(Do( new DataClass()));
}
void Start2()
{
Console .WriteLine(Do( null ));
}
int Do(DataClass data)
{
var v = new Visitor();
return v.VisitData(data);
}
}
public class DataClass
{
public int GetData()
{
return 0;
}
}
public class Visitor
{
public int VisitData(DataClass dc)
{
return dc.GetData();
}
}
*このソースコードは、 ソースコードハイライターで強調表示されました。
上記の例を使用して独立して分析を開始し、結果ツリーをナビゲートすると、プログラマーにとって興味深いすべてのノードがツリーに含まれていることがわかります。
-
dc
の直接使用（例外が発生する正確な場所） -
data
パラメーターをVisitData
メソッドにVisitData
- 「良いデータ」を使用して
Do
メソッドを呼び出します（ツリーでは、関心のあるデータが太字で強調表示されています ） -
null
Do
メソッドを呼び出すことは、あなたが探している問題です
- マイナーなステップをスキップして時間を節約
- データを便利な形式で表示します。 問題への集中を失うことなく、シンボルのすべての使用を目で追跡することなく、問題の原因を見つけることができます。
継承
今回は、インターフェース、その実装、フィールド、フィールド初期化子、コンストラクターがあります。
Main.Start
メソッドが表示できる値を把握してみましょう。 これを行うには、式
dataProvider.Foo
を選択し、Value Originを呼び出します。
public interface IInterface
{
int Foo();
}
public class Base1 : IInterface
{
public virtual int Foo()
{
return 1;
}
}
public class Base2 : IInterface
{
private readonly int _foo = 2;
public Base2()
{
}
public Base2( int foo)
{
this ._foo = foo;
}
public virtual int Foo()
{
return _foo;
}
}
public class Main
{
public void Start(IInterface dataProvider)
{
Console .WriteLine(dataProvider.Foo());
}
public void Usage()
{
Start( new Base2(3));
}
}
* This source code was highlighted with Source Code Highlighter .
バリュートラッキングの結果には以下が表示されます。
-
1
定数を返すFoo
メソッドの実装 -
Foo
メソッドの実装_foo
フィールドの値と、_foo
フィールドのすべての値のソースを返します。- コンストラクターでこのフィールドに値を割り当てる
- パラメーター
3
を使用したコンストラクター呼び出し - 値
2
このフィールドの初期化子
コレクション
次に、コレクションの操作を検討します。 次のコードを使用して、画面に表示されるすべての値のセットを見つけてみましょう。 これを行うには、
Console.WriteLine
内で
i
使用を開始し、Value Origin分析を実行します。
class Main
{
void Foo()
{
var list = new List < int >();
list.AddRange(GetData());
list.AddRange(GetDataLazy());
ModifyData(list);
foreach ( var i in list)
{
Console .WriteLine(i);
}
}
void ModifyData( List < int > list)
{
list.Add(6);
}
private IEnumerable < int > GetData()
{
return new [] { 1, 2, 3 };
}
IEnumerable < int > GetDataLazy()
{
yield return 4;
yield return 5;
}
}
* This source code was highlighted with Source Code Highlighter .
配列の明示的な作成、遅延列挙子からの値、および
Add
メソッドの呼び出しの両方が見つかりました。 いいね！
反対方向のコレクション、または値の行き先
それでは、反対の方向で試してみましょう
5
番の位置を確認してください。 それを選択して、Value Destinationを呼び出します。
public class testMy
{
void Do()
{
int x = 5;
var list = Foo(x);
foreach ( var item in list)
{
Console .WriteLine(item);
}
}
List < int > Foo( int i)
{
var list = new List < int >();
list.Add(i);
return list;
}
}
* This source code was highlighted with Source Code Highlighter .
すぐに、数
5
わかりました。
-
Foo
メソッドに渡される - コレクションに追加されました
- コレクションが返されて使用されます
- コレクションアイテムが表示されます。
この例と前の例では、値の追跡が値の追跡からコレクションの追跡に移行するとすぐに、ツリー内の対応するノードが特別なピンクのアイコンでマークされます。
ラムダス
ラムダは、それらと一緒に、特にそれらがたくさんあり、彼らが囲まれていると戦わせない場合、問題が絶えず発生します。 次の状況でR＃がどのように機能するかを見てみましょう。 この場合、両方向の値をトレースしてみましょう。
public class MyClass
{
void Main()
{
var checkFunction = GetCheckFunction();
Console .WriteLine(checkFunction(1));
}
Func< int , bool > GetCheckFunction()
{
Func< int , bool > myLambda = x =>
{
Console .WriteLine(x);
return x > 100; //
};
return myLambda;
}
}
* This source code was highlighted with Source Code Highlighter .
最初に、パラメーター
x
値がどこから来るかを探します。
Console.WriteLine
呼び出しで使用を選択し、Value Originを呼び出します。
- ラムダパラメータを含むが見つかりました
- さらに、このラムダが送信される場所を分析しました。 lambdaを追跡するすべてのノードには、特別なアイコンが付いていることに注意してください。
- 最後のステップでは、ラムダが引数
1
で呼び出されることがわかります。これはx
望ましい値です
ここで、ラムダによって返される値が使用されている場所を見つけてみましょう。
x>100
選択し、Value Destination（ R＃-> Inspect-> Value Destination ）を呼び出します。
- 分析は、ラムダ実行の結果として返される式を追跡します
- 次に、R＃はラムダが通過した場所を追跡しました
- 最後に、ラムダによって返された値を使用する
WriteLine
メソッドの呼び出しがあります。
画面（
Console.WriteLine
）の出力を2行に置き換えることで、ネストされたラムダを使用したより複雑な例を簡単に作成できます。
Func<Func< int , bool >, int , bool > invocator = (func, i) => func(i);
Console .WriteLine(invocator (checkFunction,1));
* This source code was highlighted with Source Code Highlighter .
分析は引き続き機能し、式
x>100
値がどこに行くかを簡単に把握できます。 ラムダが埋め込まれたコードは、普通の人が理解するのが非常に難しく、分析がさらに一般的になります。 さらに、ネストされたラムダのコレクションを作成しようとすることができます-それは動作します！ しかし、私はそのような演習を読者と難しい実生活に任せます。