何时使用DebuggerDisplayAttribute

Question

围绕DebuggerDisplayAttribute的一些最佳做法是什么？是什么指导您决定何时以及如何将属性应用于您的代码？例如..

1. 您是否发现DebuggerDisplayAttribute对某些类型的对象（即自定义数据结构）更有用，而不是其他对象？
2. 您是在公共类型，内部类型还是两者上定义它？
3. 您通常会将其添加到初始实施中，还是等待测试人员/用户请求它？
4. 何时更好地定义DebuggerDisplayAttribute以及何时覆盖.ToString()更有意义？
5. 您是否有关于您在属性中公开了多少数据的指南，或者要包含的计算量限制？
6. 是否应用任何继承规则，以使其更适合应用于基类？
7. 在决定何时或如何使用时还有什么需要考虑的事项吗？

Answer 1

这是主观的，我会毫不犹豫地说有任何最佳做法，但是：

  

  
1. 您是否发现DebuggerDisplayAttribute对某些类型的对象（即自定义数据结构）而非其他对象更有用？
  

到目前为止，最常见的用途是代表商业实体的类型 - 我通常会显示ID +名称。此外，任何类型都将存储在应用程序的集合中。

除此之外，每当我发现自己经常在调试器中搜索属性时，我都会添加它。

  

2.您是在公共类型，内部类型还是两者上定义它？

两个

  

3.您通常会将其添加到初始实现中，还是等待测试人员/用户请求它？

测试人员/用户永远不会看到它 - 它只在调试时使用。

  

4.定义DebuggerDisplayAttribute是否更好？何时更有意义覆盖.ToString（）？

在运行时需要表示时，覆盖ToString（），用于日志记录或特定于应用程序的目的。如果只需要调试，请使用DebuggerDisplayAttribute。

  

5.您是否有关于您在属性中公开了多少数据的指南，或者要包含的计算量限制？

因为它没有在运行时使用，唯一的限制是它应该足够快，不会妨碍调试体验（特别是当多次调用集合的元素时）。

您不需要像处理运行时日志记录那样关注敏感数据的泄露（例如，通过覆盖.ToString），因为无论如何这些数据在调试器中都是可见的。

  

6.是否应用任何继承规则，以便更有效地应用于基类？

不，将它应用于您需要的课程。

  

7.在决定何时或如何使用时，还有什么需要考虑的事项吗？

我无法想到任何其他事情。

Answer 2

没有DebuggerDisplay属性的调试模式

具有DebuggerDisplay属性的调试模式

[DebuggerDisplay("{Name,nq}")]//nq suffix means no quotes 
public class Product {

    public int Id { get; set; }

    public string Name { get; set; }

    //Other members of Northwind.Product
}

DebuggerDisplay attribute best practices

Tell the debugger what to show using the DebuggerDisplay Attribute (C#, Visual Basic, F#, C++/CLI)

Debugger/Diagnostics Tips & Tricks in Visual Studio 2019
尽管attriube很旧，您还是应该听取掌声和叙述者的反应：）顺便说一句，如果您想了解更多调试技巧，则应该在空闲时间观看此演示。

Answer 3

当我知道代码部分需要大量调试时，我会经常使用它。在浏览调试器中的对象时节省了一些时间，尤其是在使用"{ChildCollection.Count}"等表达式时。它可以让您快速了解您正在查看的数据。

我几乎总是将它放在最终会出现在集合中的类中，以便能够快速查看每个项目，而不仅仅是一堆必须扩展的MyNamespace.MyClass元素。

我的观点是ToString()用于提供数据的最终用户表示。 DebuggerDisplay适用于开发人员，您可以决定显示元素ID，一些额外的内部/私有属性。

Answer 4

有趣的是你应该问，JaredPar刚刚做了一篇名为DebuggerDisplay attribute best practices的非常好的博文。

Answer 5

DebuggerDisplay对于没有有意义的.ToString()实现的任何类都有价值，但我个人还没有看到任何人在需要之前主动编写属性。

一般来说，Omer's链接到最佳做法看起来像是合理的建议;但是我个人会偏离建议采用专用的DebuggerDisplay()方法 - 即使它是私有的，除了删除魔法字符串之外，似乎除了属性之外几乎没什么好处。