私は通常、代入後に1回だけ使用される値を変数に配置します。これは、後で使用する1行の値にカーソルを合わせることができるため、後でデバッグをより便利にするために行います。
たとえば、このコードではGetFoo（）の値にカーソルを合わせることができません。
return GetFoo();
しかし、このコードは次のことを行います。
var foo = GetFoo();
return foo; // your hover-foo is great
fooの割り当ての機能は、誰かがその値をデバッグする必要があるまで使用されないため、これは非常にYAGNI風のにおいがします。単に予見されたデバッグセッションではなかった場合、上記の最初のコードスニペットはコードをより単純に保ちます。
デバッガーの使いやすさとシンプルさの間で最良の妥協点を見つけるために、どのようにコードを記述しますか？
他のデバッガーについてはわかりませんが、統合されたVisual Studioデバッガーは、[自動]ウィンドウの関数から返されたものを報告します。returnステートメントをステップオーバーすると、戻り値は「[関数名]が返されました」と表示され、返された値が何であれ値が示されます。
gdbも同じ機能をサポートしています。「finish」コマンドは、現在の関数の残りの部分を実行し、戻り値を出力します。
これは非常に便利な機能であり、他のほとんどのデバッガーがこの機能をサポートしていなかった場合は驚きます。
「デバッガーのみの変数」のより一般的な「問題」については、本当にデバッガーのみですか？よく名付けられた一時変数を使用すると、コードの可読性も大幅に向上すると思う傾向があります。
もう1つの可能性は、コンパイラーが生成するコードを読み取ることができる十分なアセンブリプログラミングを学ぶことです。そのスキルを使用すると、値が保持されている場所（レジスタ内、メモリ内）を把握し、変数に格納しなくても値を確認できます。
このスキルは、最適化された実行可能ファイルをデバッグする必要がある場合に非常に役立ちます。オプティマイザは、シンボリックデバッグが役に立たないように、記述方法とは大幅に異なるコードを生成する可能性があります。
Visual Studioデバッガーで中間変数が必要ないもう1つの理由は、ウォッチウィンドウとイミディエイトウィンドウで関数を評価できることです。ウォッチウィンドウの場合は、評価するステートメントを強調表示してウィンドウにドラッグするだけです。
心配する価値はないと私は主張します。通常の場合、実行時のオーバーヘッドがないことを考えると、気を付けてください。複雑なステートメントを複数の単純なステートメントに分割すると、通常、読みやすさが向上すると思います。
必要になるまで割り当てを省略します。その変数を調べたいと思って、コードのそのビットにたまたま入ったことがない場合は、コードを不必要に乱雑にすることはありません。ニーズに遭遇したら、それを入れます（それは些細なExtract Variableリファクタリングであるはずです）。そして、そのデバッグセッションが終了したら、それを取り除きます（インライン変数）。デバッグが非常に多く、その特定の時点で非常に多く、前後にリファクタリングすることにうんざりしている場合は、その必要性を回避する方法を考えてください。多分もっとユニットテストが役立つでしょう。