如何避免调试器专用变量？
我通常将赋值后仅使用一次的值放入变量中。我这样做是为了让以后的调试更加方便，因为我可以将值悬停在稍后使用的一行上。
例如，此代码不允许您将鼠标悬停在 GetFoo() 的值上：
return GetFoo();
但此代码可以：
var foo = GetFoo();
return foo; // your hover-foo is great
这闻起来很 YAGNI-esque，因为foo分配的功能永远不会被使用，直到有人需要调试它的值，这可能永远不会发生。如果不是为了仅仅预见调试会话，上面的第一个代码片段会使代码更简单。
您将如何编写代码以在简单性和调试器使用方便性之间取得最佳平衡？
I commonly place into variables values that are only used once after assignment. I do this to make debugging more convenient later, as I'm able to hover the value on the one line where it's later used.
For example, this code doesn't let you hover the value of GetFoo():
return GetFoo();
But this code does:
var foo = GetFoo();
return foo; // your hover-foo is great
This smells very YAGNI-esque, as the functionality of the foo's assignment won't ever be used until someone needs to debug its value, which may never happen. If it weren't for the merely foreseen debugging session, the first code snippet above keeps the code simpler.
How would you write the code to best compromise between simplicity and ease of debugger use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我不知道其他调试器，但集成的 Visual Studio 调试器将报告“自动”窗口中函数返回的内容；一旦您跳过 return 语句，返回值将显示为“[函数名称]已返回”，其值是返回的任何值。
gdb 也支持相同的功能； “finish”命令执行当前函数的其余部分并打印返回值。
这是一个非常有用的功能，如果大多数其他调试器不支持此功能，我会感到惊讶。
至于“仅限调试器变量”的更普遍的“问题”，它们真的仅限调试器吗？我倾向于认为使用命名良好的临时变量也可以显着提高代码的可读性。
I don't know about other debuggers, but the integrated Visual Studio debugger will report what was returned from a function in the "Autos" window; once you step over the return statement, the return value shows up as "[function name] returned" with a value of whatever value was returned.
gdb supports the same functionality as well; the "finish" command executes the rest of the current function and prints the return value.
This being a very useful feature, I'd be surprised if most other debuggers didn't support this capability.
As for the more general "problem" of "debugger-only variables," are they really debugger-only? I tend to think that the use of well-named temporary variables can significantly improve code readability as well.
另一种可能性是学习足够的汇编编程，以便您可以阅读编译器生成的代码。借助该技能，您可以找出该值的保存位置（寄存器中、内存中）并查看该值，而无需将其存储在变量中。
如果您需要调试优化的可执行文件，则此技能非常有用。优化器可以生成与您编写的代码显着不同的代码，因此符号调试没有帮助。
Another possibility is to learn enough assembly programming that you can read the code your compiler generates. With that skill, you can figure out where the value is being held (in a register, in memory) and see the value without having to store it in a variable.
This skill is very useful if you are ever need to debug an optimized executable. The optimizer can generate code that is significantly different from how you wrote it such that symbolic debugging is not helpful.
在 Visual Studio 调试器中不需要中间变量的另一个原因是您可以在“监视窗口”和“立即窗口”中评估函数。对于监视窗口，只需突出显示要评估的语句并将其拖到窗口中即可。
Another reason why you don't need intermediate variables in the Visual Studio debugger is that you can evaluate the function in the Watch Window and the Immediate window. For the watch window, just simply highlight the statement you want evaluated and drag it into the window.
我认为这不值得担心。考虑到在典型情况下没有运行时开销，那就发疯吧。我认为将复杂的语句分解为多个简单的语句通常会增加可读性。
I'd argue that it's not worth worrying about. Given that there's no runtime overhead in the typical case, go nuts. I think that breaking down complex statements into multiple simple statements usually increases readability.
我会忽略该作业直到需要它。如果您从来没有碰巧在这段代码中想要查看该变量，那么您的代码就没有不必要的混乱。当您遇到需求时，将其放入（这应该是一个简单的提取变量重构）。当您完成调试会话后，将其删除（内联变量）。如果您发现自己进行了如此多的调试 - 并且在特定点进行了如此多的调试 - 以至于您厌倦了来回重构，那么请考虑如何避免这种需要；也许更多的单元测试会有所帮助。
I would leave out the assignment until it is needed. If you never happen to be in that bit of code, wanting a look at that variable, you haven't cluttered up your code unnecessarily. When you run across the need, put it in (it should be a trivial Extract Variable refactoring). And when you're done with that debugging session, get rid of it (Inline Variable). If you find yourself debugging so much - and so much at that particular point - that you're weary of refactoring back and forth, then think about ways to avoid the need; maybe more unit tests would help.