Wie Debugger-only-Variablen zu vermeiden?

Question

Ich stelle häufig in Variablen Werte, die nur einmal nach Zuordnung verwendet werden. Ich tue dies später Debuggen bequemer zu machen, als ich bin in der Lage, den Wert auf die einer Linie zu schweben, wo sie später verwendet wird.

Zum Beispiel ist dieser Code nicht lassen Sie den Wert getFoo schweben ():

return GetFoo();

Aber dieser Code tut:

var foo = GetFoo();
return foo; // your hover-foo is great

Das riecht sehr YAGNI -esque , wie die Funktionalität der foo 's Zuordnung nicht immer, bis jemand Bedürfnisse benutzt wird um seinen Wert zu debuggen, die möglicherweise passiert nie . Wenn es nicht für die nur vorgesehene Sitzung debuggen, der erste Code-Snippet oben hält der Code einfacher.

Wie würden Sie den Code besten Kompromiss zwischen Einfachheit und Leichtigkeit der Debugger Verwendung schreiben?

Answer 1

Ich weiß nicht, über andere Debugger, aber das integrierte Visual Studio-Debugger wird berichten, was aus einer Funktion in den „Autos“ Fenster zurückgegeben wurde; sobald Sie die return-Anweisung Schritt über, der die Rückgabewert zeigt sich als „[Funktionsname] zurückgegeben“ mit einem Wert, was auch immer Wert zurückgegeben wurde.

GDB unterstützt die gleiche Funktionalität wie auch; der „Finish“ Befehl, um den Rest der aktuellen Funktion ausführt und druckt den Rückgabewert.

Dies ist eine sehr nützliche Funktion zu sein, ich überrascht sein würde, wenn die meisten anderen Debugger nicht diese Funktion unterstützen.

Wie für das allgemeinere "Problem" von "Debugger-only-Variablen", sind sie wirklich Debugger-only? Ich neige dazu, zu denken, dass die Verwendung von gut genannten temporären Variablen deutlich die Lesbarkeit des Codes als auch verbessern kann.

Answer 2

Eine andere Möglichkeit ist genug Assembler-Programmierung zu erfahren, dass Sie den Code lesen kann Ihr Compiler generiert. Mit dieser Fähigkeit können Sie herausfinden, wo der Wert (in einem Register, in dem Speicher) gehalten wird, und den Wert sehen, ohne es in einer Variablen speichern zu müssen.

Diese Fähigkeit ist sehr nützlich, wenn Sie jemals brauchen werden, um eine optimierte ausführbare Datei zu debuggen. Der Optimierer kann Code generieren, die von signifikant unterschiedlich ist, wie Sie schrieb es so, dass die symbolische Testen nicht hilfreich ist.

Answer 3

Ein weiterer Grund, warum Sie nicht Zwischenvariablen in den Visual Studio-Debugger müssen, ist, dass Sie die Funktion in dem Watch-Fenster und die Direkt-Fenstern auswerten können. Für das Überwachungsfenster, markieren Sie einfach nur die Aussage, die Sie ausgewertet werden sollen, und ziehen Sie es in das Fenster.

Answer 4

Ich würde argumentieren, dass es nicht wert ist besorgniserregend zu. In Anbetracht, dass es keine Laufzeit-Overhead im typischen Fall geht Nüsse. Ich denke, dass komplexe Aussagen in mehrere einfache Aussagen brechen in der Regel Lesbarkeit erhöht.

Answer 5

würde ich den Auftrag auslassen , bis es gebraucht wird . Wenn Sie noch nie in diesem Stück Code geschehen sein, einen Blick auf diese Variable zu wollen, haben Sie Ihren Code nicht unnötig vollgestopft. Wenn Sie über die Notwendigkeit führen, setzen Sie es in (es sollte eine triviale Extract Variable sein Refactoring). Und wenn Sie mit der Debugging-Sitzung fertig sind, es loszuwerden ( Inline Variable ). Wenn Sie sich so viele Debuggen finden - und so viel an diesem bestimmten Punkt -, dass Sie von Refactoring wieder müde sind und her, dann denken Sie über die Möglichkeiten, die Notwendigkeit zu vermeiden; vielleicht mehr Unit-Tests helfen würden.